Cahier des charges chatbot relation client

Ce que le cahier des charges doit décider

Un chatbot relation client ne doit pas commencer par une longue liste de fonctionnalités.

Il doit commencer par une question plus simple : quelles demandes peut-on traiter sans dégrader la confiance du client ni compliquer la reprise par l'équipe ?

Le cahier des charges doit donc fixer cinq décisions :

• les motifs de contact priorisés ;
• les réponses autorisées et les réponses interdites ;
• les données que le chatbot peut consulter ;
• les conditions de transfert vers un conseiller ;
• les métriques qui diront si le service est réellement meilleur.

Cette structure rejoint les recommandations de conception conversationnelle : une conversation utile doit avoir un objectif, une sortie claire et une gestion des cas hors périmètre.¹

Le point le plus important est souvent oublié : le cahier des charges doit décrire un service, pas un agent conversationnel abstrait. Un service client digital a des horaires implicites, des limites, des délais, une escalade, une responsabilité métier et une définition de la réponse correcte. Si ces éléments restent hors du document, le fournisseur choisira à votre place. Il décidera quels motifs sont simples, quelles réponses peuvent être données, quelle donnée suffit, et quand il faut transférer. C'est précisément ce qu'il faut éviter.

Un bon document commence donc par la réalité opérationnelle. Quels sont les motifs qui saturent les équipes ? Quels motifs génèrent le plus de relances ? Quels motifs sont pénibles mais peu risqués ? Quels motifs semblent simples mais demandent une interprétation contractuelle, réglementaire ou commerciale ? Cette distinction change tout. Deux demandes peuvent avoir le même volume et un coût très différent. Une question sur un délai de traitement peut être automatisée rapidement. Une question sur un refus, un remboursement ou une exception doit être beaucoup plus encadrée.

Il faut aussi séparer le canal et la mission. Le chatbot peut être visible sur le site, l'espace client, une application, WhatsApp ou un portail partenaire, mais sa mission reste la même : orienter, répondre, collecter, qualifier ou transférer. Le cahier des charges doit préciser cette mission principale. Un chatbot qui essaie de tout faire devient difficile à tester. Un chatbot qui porte une mission claire peut être mesuré.

Le tableau de cadrage à mettre dans le dossier

Les critères de choix à exiger

Le fournisseur doit démontrer sa capacité à opérer le chatbot dans votre contexte, pas seulement à faire répondre un modèle.

Demandez des preuves sur :

• la gestion des droits d'accès aux contenus ;
• la traçabilité des conversations ;
• la mise à jour des réponses ;
• la qualité du transfert vers vos équipes ;
• les tests avant mise en ligne ;
• la supervision après lancement.

Chez Webotit, ce cadrage se traduit par des briques déjà documentées dans la plateforme : détection d'intention par LLM avec sortie JSON, routage vers la bonne base ou le bon parcours, mémoire conversationnelle, sources précisément isolées, export CSV des conversations et tableau de bord avec temps de réponse moyen. Ces éléments doivent apparaître dans le cahier des charges, car ils conditionnent la qualité réelle du chatbot relation client.

Le NIST rappelle qu'un système IA doit être gouverné, mesuré et surveillé selon son niveau de risque.⁴ Pour un chatbot relation client, ce point est concret : un remboursement, une garantie ou une réclamation ne se traite pas comme une question d'horaire.

Signaux de maturité avant achat

Un projet est mûr quand l'entreprise peut fournir autre chose qu'une ambition générale. La première preuve de maturité est un extrait réel de demandes entrantes : tickets, emails, conversations, formulaires, motifs de contact du centre d'appels. Sans corpus, le cahier des charges repose sur des intuitions. Or les intuitions surestiment souvent les cas spectaculaires et sous-estiment les demandes répétitives qui coûtent cher.

Le deuxième signal est l'existence d'une base de réponses exploitable. Elle n'a pas besoin d'être parfaite, mais elle doit distinguer les réponses validées, les réponses à revoir, les réponses obsolètes et les sujets sans source. Pour un chatbot relation client, la qualité de la base est un actif de production. Si elle est pauvre, le budget se déplace vers le nettoyage, la validation et la gouvernance documentaire.

Le troisième signal est la capacité à définir des sorties. Une sortie peut être une réponse donnée, un formulaire complété, un ticket créé, un conseiller alerté, une pièce demandée ou une orientation vers un bon parcours. Si le chatbot n'a pas de sortie claire, il peut converser longtemps sans retirer de charge aux équipes.

Le quatrième signal est l'accord interne sur les limites. Les métiers doivent accepter que certains sujets sortent vite vers un humain. Le juridique, la conformité, le service client et l'IT doivent savoir quels cas sont interdits, quels cas sont autorisés et quels cas exigent une trace. Cette décision évite de découvrir en recette que le périmètre est politiquement bloqué.

Exemple de scénario métier

Prenons un service client qui reçoit beaucoup de demandes sur le statut d'un dossier. Le mauvais cahier des charges dira : "Le chatbot doit répondre aux questions sur le suivi de dossier." C'est trop vague. Un fournisseur peut y voir une simple FAQ, un autre une connexion CRM, un troisième un agent capable de consulter des statuts personnalisés. Les devis seront incomparables.

Le cahier des charges utile écrit plutôt : "Le chatbot doit reconnaître les demandes de statut, demander l'identifiant nécessaire, consulter la source autorisée si elle existe, répondre uniquement avec les statuts validés, expliquer la prochaine étape, et transférer au conseiller si le statut est absent, bloqué ou sensible." Cette formulation donne un périmètre testable. Elle dit ce que l'IA détecte, quelle donnée elle consulte, quelle réponse elle peut donner et à quel moment elle s'arrête.

Ce scénario permet aussi de définir les jeux de tests. Il faut tester un dossier trouvé, un dossier non trouvé, un identifiant incomplet, un statut sensible, un client énervé, une relance déjà traitée et une demande hors périmètre. Le chatbot n'est pas validé parce qu'il répond bien à trois exemples propres. Il est validé parce qu'il sait aussi refuser, demander une précision ou transférer sans abîmer l'expérience.

Dans ce type de scénario, l'architecture Webotit apporte de la valeur quand elle combine détection d'intention, sortie structurée, source métier et reprise humaine. La conversation n'est pas un but en soi. Elle sert à produire une réponse fiable ou un transfert exploitable.

Le déroulé projet recommandé

Ce qu'il faut exclure du premier lot

Un bon cahier des charges dit aussi ce que le chatbot ne fera pas.

Excluez au départ :

• les cas juridiques ou médicaux ambigus ;
• les réclamations à forte émotion ;
• les demandes sans source fiable ;
• les actions irréversibles ;
• les promesses commerciales non validées.

Ce choix n'affaiblit pas le projet. Il le rend plus crédible. Le chatbot peut ensuite élargir son périmètre quand la base de connaissance, les règles et les reprises sont stables.

Erreurs à éviter dans un appel d'offres

La première erreur consiste à demander "un chatbot IA" sans préciser les motifs, les sources et les sorties. Ce type de demande attire des réponses très différentes : outil de FAQ, assistant génératif, connecteur CRM, interface de livechat augmentée, plateforme de bot no-code. Tout peut sembler comparable en démonstration, mais rien ne l'est en production.

La deuxième erreur consiste à confondre taux d'automatisation et qualité de service. Un taux d'automatisation élevé peut cacher des clients mal orientés, des réponses incomplètes ou des transferts qui obligent le conseiller à tout reprendre. Le bon indicateur n'est pas seulement "combien de conversations le chatbot absorbe". C'est "combien de demandes sont utilement résolues ou transmises avec un contexte exploitable".

La troisième erreur consiste à oublier l'administration. Qui ajoute une réponse ? Qui retire une réponse périmée ? Qui relit les conversations ? Qui décide qu'un motif peut passer en production ? Qui analyse les demandes non comprises ? Si ces rôles ne sont pas définis, le chatbot se dégrade après le lancement.

La quatrième erreur consiste à demander trop d'intégrations dès le début. Une intégration utile vaut mieux que cinq intégrations décoratives. Si la donnée n'est pas nécessaire pour répondre, elle complique le projet. Si elle est nécessaire, elle doit être documentée, sécurisée et testée.

Ce que Webotit met concrètement dans le périmètre

Sur un projet relation client, Webotit ne traite pas le chatbot comme une fenêtre de dialogue isolée. Le périmètre se construit autour des motifs, des sources et des reprises. La détection d'intention par LLM sert à comprendre si l'utilisateur demande une information, un suivi, une orientation, une action ou une sortie humaine. La sortie JSON permet de router la demande vers le bon traitement au lieu de se limiter à une réponse libre.

La base de connaissance et le RAG servent à ancrer les réponses dans des contenus validés. Le but n'est pas que le modèle improvise une réponse agréable. Le but est que chaque information importante repose sur une source connue, maintenable et contrôlable. Quand une donnée métier est nécessaire, le périmètre doit préciser quelle API est lue, avec quels droits et pour quel motif.

La mémoire conversationnelle permet de garder le contexte utile pendant l'échange. Elle évite de redemander une information déjà donnée, mais elle ne doit pas devenir une collecte excessive. La reprise humaine transmet le motif, les informations collectées, l'historique court et la raison du transfert. C'est souvent là que se joue le ROI : si l'humain reprend avec du contexte, le chatbot a réduit le travail ; sinon il a seulement déplacé l'attente.

Enfin, la supervision doit être prévue dès le cahier des charges. Export des conversations, tableau de bord, recherche dans les échanges, feedback utilisateur, analyse des intentions non comprises : ces éléments ne sont pas du confort. Ils permettent de faire progresser le service sans repartir de zéro.

Checklist avant consultation fournisseur :

• vérifier que les motifs prioritaires ont un volume, une source et une sortie ;
• demander un exemple de conversation avec réponse sourcée et transfert ;
• exiger un export des conversations pour la supervision ;
• préciser qui valide les réponses, les exclusions et les élargissements.

Signaux à vérifier en démo :

• l'intention détectée est visible et explicable ;
• la source utilisée apparaît dans la réponse ou le journal ;
• la sortie JSON peut être relue par l'équipe projet ;
• la reprise humaine conserve le contexte utile.

Le cahier des charges doit aussi cadrer l'intégration IT client. Un agent IA Webotit devient plus utile quand il connaît le statut d'un dossier, le segment client, le canal d'origine, les droits d'accès et les actions autorisées. Cette personnalisation ne doit pas venir d'une mémoire floue : elle doit venir de connexions maîtrisées au CRM, à l'outil de ticketing, au SSO, aux API métier ou à l'espace client.

Cette couche d'intégration permet aussi d'orchestrer plusieurs agents IA Webotit sans casser le parcours. Le chatbot relation client peut qualifier une demande, le mailbot peut retrouver un échange asynchrone, le callbot peut reprendre un motif vocal, et l'agent back-office peut préparer une action interne. Le point commun doit être un contexte structuré, vérifiable et limité aux données nécessaires.

Livrables attendus en fin de cadrage

Avant de demander un chiffrage ferme, exigez des livrables simples mais précis. La matrice motifs-réponses-transferts doit lister chaque motif, son volume estimé, sa source, sa réponse autorisée, son risque et sa sortie. La cartographie des sources doit préciser les documents, bases, API et droits d'accès. Le plan de tests doit couvrir les cas nominalement simples et les cas limites.

Le dossier doit aussi contenir une définition des KPI. Pour un chatbot relation client, les indicateurs utiles sont le taux de résolution utile, le taux de transfert avec contexte, le taux de reprise évitée, la satisfaction après échange, les demandes non comprises et le volume de relances. Ces chiffres ne doivent pas être décoratifs. Ils doivent orienter les arbitrages de périmètre après lancement.

Enfin, le cahier des charges doit prévoir un mode d'amélioration. Un chatbot relation client n'est pas un projet figé. Les motifs évoluent, les offres changent, les documents se périment, les clients utilisent des formulations nouvelles. Le dispositif doit donc inclure une boucle d'amélioration : observation, correction, validation métier, publication, mesure. C'est cette boucle qui transforme un lancement correct en actif durable.

Critères d'acceptation avant publication

Avant mise en ligne, chaque motif doit être accepté sur preuve. L'équipe doit vérifier que le chatbot comprend plusieurs formulations naturelles, répond avec la bonne source, refuse les sujets interdits, demande une précision quand il manque une information et transmet le contexte au bon moment. Cette recette doit être documentée, pas seulement validée en réunion.

Le lancement peut ensuite rester progressif. Ouvrir le chatbot sur un premier périmètre, observer les conversations, corriger les réponses et élargir ensuite vaut mieux qu'un lancement large et fragile. Le cahier des charges doit donc prévoir un jalon de go/no-go et des critères d'élargissement.

FAQ