Bonnes pratiques pour concevoir un chatbot vraiment utile en entreprise

8 avril 2026 10:00 · Go Komura · IA, Chatbot, Création de site web, Amélioration du parcours de demande, Base de connaissances

Cet article présente les principes généraux pour construire des chatbots de contact pour site web, des bots FAQ internes et des bots de première réponse. Un chatbot qui fonctionne bien a son rôle, ses sources de connaissances, ses permissions, ses conditions de transfert et sa méthode d’évaluation définis avant même la question de « l’intelligence du modèle ».

Quand on parle de chatbot, il est tentant de commencer par « quel modèle utiliser », « faut-il faire du RAG » ou « faut-il une architecture multi-agents ». Mais l’ordre qui paie vraiment en pratique est un peu différent.

Ce qu’il faut décider en premier, c’est à qui il s’adresse, quelle tâche il doit alléger, et jusqu’où. Quand cet ordre est bousculé, la conversation peut sembler pertinente, mais elle ne se traduit ni par des demandes de contact ni par un gain d’efficacité opérationnelle.

Cette tendance est particulièrement marquée sur les sites techniques et B2B. La valeur ne vient pas du fait de faire durer la conversation. Elle vient du fait de présenter le service avec précision et, si nécessaire, d’orienter vers la bonne page ou la bonne personne. Les principaux guides de développement actuels partent eux aussi largement du principe que, pour une qualité de production, l’évaluation, l’ancrage (grounding), les garde-fous et le transfert doivent être conçus comme des éléments séparés.¹²³⁴⁵⁶

Table des matières

1. La conclusion d’abord
2. Poser d’abord la vue d’ensemble
3. Décider d’abord « à qui, quelle tâche, on va l’alléger »
4. La conception de la conversation avant le choix du modèle
5. La conception des connaissances détermine l’essentiel de la qualité
6. Le prompt : des règles d’exploitation courtes plutôt qu’un long profil de personnalité
7. La conception de la sécurité ne se limite pas à « bloquer les questions dangereuses »
8. Décider dès le départ les conditions de transfert vers un humain
9. Améliorer sans évaluation revient presque à s’en remettre au hasard
10. Sur un site web, concevoir le chatbot avec le parcours de contact comme un tout
11. Un plan sur 90 jours pour poser les bases
12. Erreurs courantes
13. Résumé
14. Articles connexes
15. Références

1. La conclusion d’abord

Pour le dire de façon un peu brute, mais sous une forme facile à utiliser en pratique :

1. Un chatbot est plus solide quand on décide d’abord un seul et unique usage.
2. Avant le modèle, il faut décider sur quoi il fonde ses réponses.
3. Il faut distinguer les réponses qui ne peuvent citer aucune source de celles qui doivent être transmises à un humain.
4. Plus une opération est à risque, moins il faut alléger les permissions et les étapes de confirmation.
5. En production, sans journaux de conversation ni jeu d’évaluation, l’amélioration relève presque du hasard.
6. Sur un site web, aider les visiteurs à comprendre les pages et à atteindre le parcours de contact a souvent plus de valeur que de faire durer la conversation.

Un chatbot bien conçu est réellement utile. Mais si on l’étend en guichet universel qui répond à tout, la précision, l’exploitation et le périmètre de responsabilité s’effondrent tous en même temps. Commencer étroit puis étendre à partir des domaines où il aide de façon fiable est, au final, plus rapide.⁷

2. Poser d’abord la vue d’ensemble

D’abord, la vue d’ensemble.

flowchart LR
    A[Question de l'utilisateur] --> B{Dans le périmètre}
    B -->|Oui| C[Recherche de connaissances / appel d'outil]
    B -->|Non| H[Page de contact / orientation vers un responsable]
    C --> D{Permissions et conditions de sécurité remplies}
    D -->|Oui| E[Réponse avec source + action suivante]
    D -->|Non| F[Transfert vers un humain]
    E --> G[Journaux / évaluation / amélioration]
    F --> G
    H --> G

Ce qui compte dans ce schéma, c’est qu’un chatbot n’est pas un simple prompt : c’est un système qui inclut le parcours, les connaissances, les permissions et l’évaluation. Il doit être conçu non seulement pour répondre aux questions, mais aussi pour couvrir les conditions dans lesquelles il répond, celles dans lesquelles il ne répond pas, et ce vers quoi il oriente ensuite.

Les principales suites d’outils actuelles sont elles aussi construites sur cette logique. Google Cloud porte les webhooks, les handoff rules et l’évaluation comme des fonctionnalités séparées, et OpenAI conseille de figer les model snapshots et de construire des evals comme base de l’exploitation en production.¹²⁸³⁴ Autrement dit, la première bonne pratique consiste à ne pas essayer de tout résoudre avec le seul prompt.

3. Décider d’abord « à qui, quelle tâche, on va l’alléger »

Avant de construire un chatbot, limitez d’abord l’usage à un seul objectif. Tant que ce point reste flou, ni les critères d’évaluation ni la conception des connaissances ne peuvent être fixés.

En tableau, les usages se résument ainsi.

Parmi ces usages, le plus facile à construire en premier est celui dont le périmètre est étroit et dont la source de vérité de la réponse est facile à déterminer. Par exemple,

• la réponse de premier niveau à une FAQ produit,
• la présentation du service avant une demande de contact,
• la recherche dans les procédures internes

sont des cas faciles pour démarrer.

À l’inverse,

• les décisions contractuelles,
• la fixation des prix,
• les approbations d’exception,
• les demandes fortement marquées par des conditions propres à chaque client

sont plus sûres à ne pas transformer en terrain de jeu principal dès le départ.

Par ailleurs, il n’y a pas beaucoup de cas où une architecture multi-agents est nécessaire dès le départ. Microsoft indique lui aussi qu’un agent unique simplifie l’implémentation, réduit la charge d’exploitation et donne un modèle d’exécution plus prévisible, et recommande de valider d’abord avec un agent unique, sauf raison claire de séparer.⁷

4. La conception de la conversation avant le choix du modèle

Une des raisons pour lesquelles les chatbots échouent est que l’entrée et la sortie de la conversation ne sont pas définies. Se contenter d’un « saisissez librement ce que vous voulez » brouille la frontière entre ce que le bot peut faire et ce qu’il ne peut pas faire.

4.1 Fixer l’entrée de la conversation

Les choses sont plus stables lorsque le premier message montre d’abord le périmètre couvert. Pour un bot de site web, par exemple, présenter dès le départ

• les sujets qu’il peut traiter,
• les pages qu’il peut indiquer immédiatement,
• les informations minimales nécessaires pour une consultation

réduit les dérives de la conversation.

Si des boutons ou des réponses rapides sont disponibles, poser dès le départ des embranchements comme

• je veux connaître les tarifs
• je veux savoir si vous pouvez traiter tel cas
• je veux voir des exemples de réalisations
• je veux vous contacter

est nettement plus stable qu’une saisie libre seule.

4.2 Ne demander que le minimum d’informations

Les seuls éléments qu’il vaut la peine de demander à l’utilisateur sont ceux qui changent la réponse ou l’orientation. Ajouter des champs simplement parce que « ça semble utile à savoir » augmente l’abandon.

Par exemple, si

• le secteur d’activité,
• le type de demande,
• la présence ou non d’un système existant,
• l’urgence

changent la suite proposée, alors il est utile de les demander. À l’inverse, les informations qui ne seront pas utilisées immédiatement sont mieux reportées à plus tard.

4.3 Décider comment terminer une réponse

Une bonne réponse ne se termine pas avec le seul corps du texte.

Terminer dans l’ordre

1. conclusion,
2. justification ou source,
3. prochaine action possible

permet de relier la conversation au travail concret.

Pour les bots de site web en particulier, la valeur ne vient pas tant de tout boucler dans le chat que d’une prochaine étape claire :

• passer à la page de service concernée,
• consulter des exemples de réalisations,
• passer au formulaire de contact.

4.4 Séparer les sujets à haut risque dans un parcours dédié

Les domaines à haut risque comme l’authentification, les données personnelles (PII), les montants, les contrats ou les approbations d’exception sont plus sûrs en dehors du même parcours que le guidage ordinaire. Les handoff rules de Google Cloud montrent explicitement des exemples de renvoi des demandes à haut risque vers un agent spécifique.³

5. La conception des connaissances détermine l’essentiel de la qualité

La qualité d’un chatbot se dégrade plus facilement à cause de ses connaissances qu’à cause de son modèle. Si l’information à l’origine des réponses est ambiguë, aucun modèle ne sera stable.

5.1 Décider d’abord « qu’est-ce qui fait foi »

Au minimum, il faut décider ceci.

• Quels documents ou pages font foi
• Qui est responsable des mises à jour
• À quelle fréquence ils sont mis à jour
• Quand l’information périmée est abandonnée

Sans cela, le bot capte à la fois des informations anciennes et récentes. Et cette incohérence est, avec une forte probabilité, visible par l’utilisateur.

5.2 Découper par unité de sens, pas par page

L’échec classique du RAG consiste à injecter des PDF ou des pages tels quels et à considérer que c’est terminé. En pratique, les réponses sont plus stables lorsque le contenu est traité en unités de sens :

• une explication de dispositif,
• une procédure,
• une FAQ,
• une mise en garde.

Microsoft indique que la qualité du RAG dépend de la préparation du contenu, et présente le chunking, la vectorisation, la recherche hybride et le semantic ranking comme la base à suivre.⁵ La file search d’OpenAI suppose elle aussi la réécriture de requêtes, des recherches multiples, la recherche keyword + semantic, et le reranking.⁹ Autrement dit, la bonne pratique n’est pas « d’insérer les documents », mais « de transformer les documents en connaissances consultables ».

5.3 Afficher les sources et les dates de mise à jour

Ce qui rassure les utilisateurs, ce n’est pas un bot qui parle bien, mais un bot dont on peut retracer les fondements.

Une conception qui peut montrer

• quelle page a servi de base à la réponse,
• quel point de quel document,
• quand l’information a été mise à jour

facilite aussi l’investigation en cas de mauvaise réponse.

La recherche web d’OpenAI est conçue pour retourner des réponses accompagnées de sources, et Microsoft Copilot Studio décrit lui aussi des réponses ancrées et citées (grounded, cited responses).¹⁰¹¹ Lorsqu’on répond à partir du site ou de documents internes, viser cet état de « fondements traçables » facilite aussi l’exploitation.

5.4 Séparer les informations récentes vers une recherche externe

Pour les sujets où la fraîcheur de l’information compte, mieux vaut ne pas répondre uniquement à partir de connaissances figées.

Par exemple :

• les jours ouvrés,
• les révisions de prix,
• les informations de recrutement,
• les informations d’incident,
• les changements réglementaires ou légaux.

Pour ce type de question, il est plus sûr de consulter le site ou l’API source par un parcours séparé, ou de répondre explicitement « veuillez vérifier cette page pour les informations les plus récentes ». Lorsqu’on utilise des sites publics comme source de connaissances, il faut aussi limiter au préalable les domaines auxquels on fait confiance. Copilot Studio suppose lui aussi une recherche restreinte à des domaines configurés, avec citations et vérification de pertinence (relevance check).¹¹

6. Le prompt : des règles d’exploitation courtes plutôt qu’un long profil de personnalité

Ce qui fonctionne vraiment dans le prompt d’un chatbot, ce n’est pas un long profil de personnalité, mais des règles d’exploitation courtes et claires.

Au minimum, il est utile de séparer en 4 couches.

1. Rôle
2. Connaissances et outils autorisés
3. Conditions pour répondre / conditions pour transférer
4. Format de la réponse

Par exemple, le rôle peut s’écrire brièvement : « guider avant une demande de contact », « guider dans les procédures internes ». Le format de réponse aussi : « conclusion → justification → action suivante » suffit.

À l’inverse, un prompt faible ressemble souvent à ceci :

• seul le profil de personnalité est long
• la justification des réponses est vague
• les conditions d’utilisation des outils ne sont pas claires
• les conditions de transfert ne sont pas écrites

6.1 Utiliser une sortie structurée

Dans les cas qui alimentent un traitement en aval — statut de commande, créneau de réservation, classification de la demande — il est plus sûr de ne pas se limiter au texte libre. OpenAI décrit lui aussi le retour de JSON via les Structured Outputs.¹

Il vaut mieux séparer le texte destiné aux humains des valeurs destinées aux machines. Par exemple, ne serait-ce que séparer en

• texte affiché : l’explication montrée à l’utilisateur,
• intent : le type de demande,
• confidence : le degré de confiance du jugement,
• next_action : la prochaine étape du parcours

stabilise déjà l’exploitation.

6.2 Figer la version du modèle, et évaluer avant de la changer

En production, « la réponse est un peu différente aujourd’hui par rapport à hier » est un incident. OpenAI recommande de figer (pin) un model snapshot pour les applications de production et de construire des evals qui mesurent le comportement du prompt.¹ De plus, l’optimisation est explicitement présentée comme une boucle continue evals → prompt engineering → fine-tuning.²

6.3 Répartir les modèles selon la tâche

Il n’est pas non plus nécessaire de tout faire porter par un seul modèle. OpenAI conseille lui aussi d’utiliser les modèles de la famille GPT pour un traitement à faible latence et bien défini, et les modèles de raisonnement pour les jugements complexes et fortement ambigus.¹²

En pratique, répartir ainsi :

• un modèle léger pour les réponses FAQ et la classification,
• un modèle de raisonnement pour la détection d’exceptions et les résumés complexes,
• un humain pour les jugements à haut risque

tend à stabiliser à la fois le coût et la qualité.

7. La conception de la sécurité ne se limite pas à « bloquer les questions dangereuses »

Quand on parle de « conception de la sécurité », on imagine surtout le blocage des questions nuisibles. Mais ce n’est pas tout ce qui compte en pratique.

7.1 Partir du principe du prompt injection

Pour les bots basés sur un LLM, mieux vaut partir du principe du prompt injection. Microsoft distingue les types direct et indirect, et signale que des instructions cachées intégrées dans des sites externes ou des fichiers peuvent même détourner la session.⁶¹³

Autrement dit, pour un bot qui lit des documents externes ou des pages web, il faut

• ne pas traiter le contenu externe sur le même plan que les instructions système,
• réduire au minimum les permissions d’exécution des outils,
• insérer une confirmation avant toute opération à haut risque.

7.2 Réduire les permissions au minimum

« Il peut lire tous les documents auxquels il a accès » ou « il peut exécuter toutes les opérations qu’il peut appeler » sont des situations dangereuses. Les recommandations de sécurité de Microsoft insistent elles aussi sur le moindre privilège et sur l’isolation de l’influence du contenu externe.⁶

Pour les bots internes en particulier, il est utile de décider à l’avance :

• les permissions de consultation par service,
• la séparation des informations par client,
• l’exclusion des documents contenant des données personnelles.

7.3 Traiter les données personnelles et l’authentification dans une couche séparée

Mieux vaut ne pas supposer que « le bot masquera correctement les informations tout seul ». La documentation de Microsoft sur l’ancrage à des sites web publics indique explicitement que les données personnelles saisies par l’utilisateur ne sont pas automatiquement nettoyées ou masquées (scrub / mask).¹¹

Si vous traitez des données personnelles ou des données propres à un client, il faut concevoir le système pour :

• effectuer l’authentification côté application,
• restreindre les informations récupérables,
• conserver des journaux d’audit,
• satisfaire les conditions de vérification d’identité avant de répondre.

7.4 La sécurité se traite dès le début, pas à la fin du développement

Le Generative AI Profile du NIST part lui aussi du principe que le risque doit être géré à chaque étape : conception, développement, usage et évaluation.¹⁴ Autrement dit, la conception de la sécurité n’est pas un dernier point de contrôle avant la sortie, elle doit figurer dans le cahier des charges dès le départ.

8. Décider dès le départ les conditions de transfert vers un humain

Une conception qui se limite à la phrase « si je ne sais pas, je transfère au responsable » est fragile. En réalité, il faut décider selon quelles conditions, vers qui, et avec quelles informations jointes.

Par exemple, les conditions suivantes sont faciles à poser dès le départ.

• Les questions nécessitant une authentification
• Les questions nécessitant une confirmation de contrat ou de prix
• Les questions pour lesquelles aucune source ne peut être citée
• Les questions que le bot n’a pas su traiter correctement à deux reprises ou plus
• Les réclamations ou les demandes très urgentes
• Les demandes dans des domaines à haut risque comme le juridique, le social ou le médical

Les handoff rules de Google Cloud indiquent explicitement qu’un contrôle déterministe peut être utilisé plutôt qu’un transfert basé sur des instructions.³ Plus le domaine est à risque, plus il est facile d’opérer avec « on transfère toujours dans ces conditions » plutôt qu’avec « on transfère probablement ».

Il est également utile de décider à l’avance quelles informations transmettre à l’humain lors du transfert.

• L’historique de la conversation jusqu’à ce point
• Les éléments déjà recueillis
• Les pages ou documents consultés
• La raison du blocage du bot
• Les points à vérifier ensuite

La seule réunion de ces cinq éléments réduit déjà nettement les reprises de travail après le transfert.

9. Améliorer sans évaluation revient presque à s’en remettre au hasard

L’habitude la plus dangereuse dans l’amélioration d’un chatbot est de lire quelques conversations et d’avancer sur la base d’un « ça semble bien meilleur ». De cette façon, chaque ajustement du prompt casse autre chose.

OpenAI recommande d’écrire d’abord des evals, et de les faire tourner sur des entrées proches de l’usage réel.² Autrement dit, le point de départ de l’amélioration est le jeu d’évaluation, pas le prompt.

9.1 Les indicateurs minimums à avoir

Le CX Agent Studio de Google Cloud organise lui aussi la satisfaction de l’objectif utilisateur, la justesse des outils, les hallucinations, etc. comme indicateurs d’évaluation.⁴ Cette façon de penser se transpose bien à n’importe quelle implémentation.

9.2 L’amélioration est une boucle, pas un remède miracle

Pour l’ordre de l’amélioration, ceci suffit globalement.

flowchart LR
    A[Construire un jeu d'évaluation] --> B[Mesurer le prompt / modèle actuel]
    B --> C[Classer les cas d'échec]
    C --> D[Corriger les connaissances / le prompt / le routing / le transfert]
    D --> E[Réévaluer]
    E --> F[Surveillance en production]
    F --> A

Sans cette boucle, l’amélioration dépend de l’intuition individuelle. Avec elle, on peut suivre plus facilement « ce qui s’est amélioré et ce qui s’est dégradé ».

10. Sur un site web, concevoir le chatbot avec le parcours de contact comme un tout

Pour un chatbot placé sur le site d’une entreprise, le chat lui-même n’est pas forcément la vedette. Dans la plupart des cas, il est plus naturel de le concevoir comme une ligne d’appui qui

• indique quel type d’entreprise il s’agit,
• oriente vers la bonne page de service,
• fait apparaître des exemples de réalisations ou des FAQ,
• réduit les inquiétudes avant la demande de contact.

Sur les sites techniques et B2B en particulier, la description des services est complexe. C’est pourquoi, plutôt que de tout dire dans le chat, orienter vers la bonne page est souvent plus efficace.

Par exemple, le flux suivant fonctionne plutôt bien.

1. Confirmer le type de demande
2. Orienter vers la page de service concernée
3. Faire apparaître, si nécessaire, des exemples de réalisations ou des FAQ liés
4. S’il reste des points flous, ne demander que le minimum
5. Relier vers le formulaire de contact

Sous cette forme, le chat devient un appui pour le parcours commercial et de contact. À l’inverse, placé sans lien avec le parcours des pages, il devient facilement « une boîte capable de parler mais qui ne mène nulle part ».

11. Un plan sur 90 jours pour poser les bases

Il n’est pas nécessaire de démarrer en grand. Pour poser les bases en 90 jours, l’ordre suivant est réaliste.

Semaines 0-2 : décider l’usage et la source de vérité

• Décider quelles demandes on veut réduire
• Décider les utilisateurs ciblés
• Décider les documents faisant foi et leur responsable de mise à jour
• Décider les conditions de transfert vers un humain

Semaines 3-6 : prototyper à petite échelle

• Construire un prototype limité aux scénarios principaux
• Construire le message d’entrée et les embranchements
• Rendre possible le retour de réponses avec sources
• Construire un jeu d’évaluation de 20 à 50 cas

Semaines 7-10 : affiner en pilote

• Consulter les journaux des utilisateurs réels
• Classer les questions qui posent problème
• Corriger d’abord les connaissances et le routing, avant le prompt
• Renforcer les conditions de transfert là où ça ne fonctionne pas bien

Semaines 11-12 : fixer le mode de fonctionnement en production

• Décider les indicateurs suivis chaque semaine
• Figer et gérer les versions du prompt / du modèle
• Décider le flux de mise à jour et son responsable
• Décider s’il faut étendre vers un deuxième usage

Progresser dans cet ordre réduit les risques de construire trop grand dès le départ et de s’effondrer.

12. Erreurs courantes

Pour finir, un récapitulatif des erreurs les plus fréquentes.

12.1 En faire un guichet universel qui répond à tout

Élargir trop la portée dès le départ rend à la fois la précision et le périmètre de responsabilité flous. Limiter l’usage à un seul objectif est plus solide.

12.2 Pas de source de vérité ni de responsable des mises à jour

Même avec un dispositif RAG en place, rien ne se stabilise si l’information source n’est pas organisée. L’exploitation des connaissances est un travail à part.

12.3 Affirmer sans source

Une réponse qui paraît plausible est ce qu’il y a de plus dangereux en exploitation. Une réponse dont on ne peut pas retracer le fondement est difficile à corriger après coup.

12.4 Laisser exécuter directement des opérations à haut risque

Des opérations comme un virement, un renouvellement de contrat ou la consultation de données personnelles ne doivent jamais se passer de confirmation ou d’approbation humaine.

12.5 Transfert vers un humain resté vague

Si tout ce qui est écrit est « transférer au responsable si nécessaire », le terrain se retrouve bloqué. Il faut décider les conditions, le destinataire et les informations à joindre.

12.6 Pas de jeu d’évaluation

À chaque amélioration, on ne sait plus si les choses se sont améliorées ou dégradées. C’est un cas extrêmement fréquent.

12.7 Adopter une architecture multi-agents dès le départ

Ajouter des agents augmente la liberté de conception. Mais en même temps, la latence, la gestion d’état, la surveillance, le débogage et la gestion des permissions s’alourdissent aussi. Sauf raison de séparation nécessaire, tester d’abord avec un seul agent est plus sûr.⁷

13. Résumé

Si l’on devait résumer en une phrase les bonnes pratiques de création de chatbot, ce serait : décider le rôle, les connaissances, les permissions, le transfert et l’évaluation avant de choisir le modèle.

Les 5 points particulièrement importants sont les suivants.

• Limiter l’usage à un seul objectif
• Décider la source de vérité et les citations
• Séparer les domaines à haut risque
• Formaliser par écrit les conditions de transfert vers un humain
• Faire tourner une évaluation proche de l’usage réel

Que ce soit pour un site web ou pour un usage interne, cet ordre reste largement le même. En concevant le chatbot non pas comme « quelque chose qui parle bien », mais comme « quelque chose qui organise où raccourcir le travail et où le relier à un humain », on réduit nettement le risque d’échec.

Articles connexes

• Pourquoi une entreprise devrait avoir un site web - Aller au-delà d’une simple brochure et générer du profit
• Comment relier les articles et les pages de service - Les bases de la conception des liens internes
• Comment construire des pages de service - Une méthode d’organisation pour le B2B technique
• Les trois endroits à corriger en premier sur un site qui ne génère pas de demandes de contact
• Bonnes pratiques SEO et Google Ads - Un plan général pour l’acquisition par la recherche

Références

Services liés à cette thématique

Cet article se relie aux pages de service suivantes. Entrez par celle qui vous semble la plus proche.

Amélioration du parcours de contact d’un site web

Un chatbot sur un site web est plus efficace lorsqu’il est conçu en intégrant l’orientation vers la FAQ, les pages de service et la page de contact.

Voir Amélioration du parcours de contact d’un site web Nous contacter

Création de site web

Un chatbot sur un site web est plus efficace lorsqu’il est conçu conjointement avec la structure des pages, les CTA et la page de contact.

Voir Création de site web Nous contacter

Création de site web (révision du SEO et du parcours de contact)

Un chatbot est aussi étroitement lié à la conception du parcours : comment orienter les visiteurs venus de la recherche ou de la publicité, et comment les mener jusqu’à une demande de contact.

Voir Création de site web Nous contacter

Profil de l’auteur

Voici la page de profil de l’auteur de cet article.

Go Komura

Représentant, KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’investigation de dysfonctionnements, avec des points forts sur les projets impliquant des actifs existants et les enquêtes sur des pannes dont la cause est difficile à identifier. À l’aise également pour transformer des activités au contexte technique complexe en une structure de pages et des textes qui communiquent clairement.

Voir le profil Nous contacter

Liens publics

• GitHub
• X

Retour à la liste du blog

Nous contacter

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Que faut-il décider en premier lorsqu'on met en place un chatbot ?

Avant même de choisir un modèle, il faut d'abord limiter l'usage à un seul objectif : à qui il s'adresse, quelle tâche il doit alléger, et jusqu'où. Si ce point reste flou, ni les critères d'évaluation ni la conception des connaissances ne peuvent être fixés. Pour un premier projet, il est plus facile de choisir un périmètre étroit où la source de vérité de la réponse est facile à déterminer : la réponse de premier niveau à une FAQ produit, la présentation du service avant une demande de contact, ou la recherche dans les procédures internes en sont de bons exemples. Les domaines à haut risque, comme les décisions contractuelles ou la fixation des prix, ne devraient pas être le terrain de jeu principal dès le départ.

Comment stabiliser la qualité des réponses d'un chatbot ?

La qualité se dégrade plus souvent à cause des connaissances que du modèle. Il faut donc d'abord décider quels documents ou pages font foi, qui est responsable de leur mise à jour, et à quelle fréquence ils sont actualisés. Pour le RAG, plutôt que d'injecter des PDF ou des pages tels quels, les réponses sont plus stables si le contenu est découpé en unités de sens, comme une procédure ou une FAQ. De plus, en concevant le système pour qu'il affiche la page consultée et la date de mise à jour de la source, l'investigation en cas de réponse erronée devient beaucoup plus simple.

Comment concevoir le transfert d'un chatbot vers un humain ?

Une conception qui se limite à la phrase « si je ne sais pas, je transmets au responsable » est fragile : il faut aussi décider selon quelles conditions, vers qui, et avec quelles informations jointes. Des conditions faciles à poser dès le départ incluent les questions nécessitant une authentification, celles qui exigent une confirmation de contrat ou de prix, celles pour lesquelles aucune source ne peut être citée, ou celles que le bot n'a pas su traiter correctement à deux reprises ou plus. Au moment du transfert, remettre à la personne l'historique de la conversation, les informations déjà recueillies, les documents consultés, la raison du blocage du bot et les points à vérifier ensuite — ces cinq éléments réduisent nettement les reprises de travail après le transfert.

Quelles sont les erreurs courantes lors de la mise en place d'un chatbot ?

Les plus fréquentes sont : en faire un guichet universel qui répond à tout, en élargissant trop la portée ; ne pas définir de source de vérité ni de responsable des mises à jour ; laisser le bot affirmer des choses sans pouvoir citer de source ; laisser exécuter directement des opérations à haut risque ; laisser les conditions de transfert vers un humain rester vagues ; ne pas disposer d'un jeu d'évaluation ; et adopter d'emblée une architecture multi-agents. Sans jeu d'évaluation, on ne sait plus, à chaque modification du prompt, si les choses se sont améliorées ou dégradées, et l'amélioration devient pratiquement une affaire de chance.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.