Modèle de cahier des charges pour un projet chatbot

Un projet chatbot mal cadré part souvent sur la mauvaise question. Au lieu de demander "quelle IA choisir ?", il faut d'abord préciser ce que l'utilisateur veut accomplir, ce que le bot doit comprendre, quelles données il peut utiliser et à quel moment un humain reprend la main.¹²³⁴

1. À quoi sert vraiment un cahier des charges chatbot ?

Un cahier des charges sert à aligner tout le monde avant la phase de construction :

• métier ;
• service client ;
• marketing ;
• DSI ;
• conformité ;
• prestataire.

IBM recommande de partir des questions fréquentes réelles des utilisateurs, puis de transformer ces besoins en objectifs conversationnels concrets.¹

Le document ne doit donc pas être un catalogue de fonctionnalités abstraites. Il doit répondre à une question simple : qu'est-ce que le chatbot doit faire progresser, pour qui, avec quelles limites ?

2. Les sections indispensables

2.1 Le problème à résoudre

Décrivez la friction actuelle :

• trop d'appels ou d'emails répétitifs ;
• faible disponibilité du service client ;
• abandon dans un tunnel de vente ;
• difficulté à orienter un usager ;
• lenteur de traitement côté back-office.

2.2 Les publics concernés

Précisez pour qui le bot est conçu :

• prospects ;
• clients ;
• adhérents ;
• patients ;
• usagers ;
• équipes internes.

Un même projet peut couvrir plusieurs publics, mais il faut l'écrire noir sur blanc.

2.3 Les cas d'usage prioritaires

La première version doit rester concentrée. Listez les demandes réellement visées au lancement, par exemple :

• obtenir un document ;
• suivre un dossier ;
• qualifier un besoin ;
• recommander un produit ;
• prendre un rendez-vous ;
• répondre à une FAQ métier.

2.4 Les intentions, les données et le contexte

Google rappelle qu'un intent sert à catégoriser l'intention de l'utilisateur, qu'une entité structure les données utiles extraites de la demande, et que le contexte permet de garder le fil de la conversation.²³⁴

Dans le cahier des charges, il faut donc déjà noter :

• les demandes à reconnaître ;
• les informations à extraire ;
• les éléments de contexte à mémoriser pendant le parcours.

2.5 Les canaux de diffusion

Indiquez où le chatbot sera disponible :

• site web ;
• espace client ;
• application mobile ;
• WhatsApp ;
• téléphone ;
• intranet.

Le canal change souvent les contraintes de design, de temps de réponse et d'identification utilisateur.

2.6 Les sources de connaissance

Listez les sources autorisées :

• FAQ ;
• base documentaire ;
• fiches produit ;
• CRM ;
• ERP ;
• base de dossiers ;
• formulaires ou workflows existants.

Le bot ne doit pas "inventer". Il doit s'appuyer sur des sources définies.

2.7 Les règles de transfert humain

IBM rappelle qu'un assistant conversationnel doit offrir une alternative quand il ne couvre pas correctement une demande complexe.¹

Le cahier des charges doit donc préciser :

• quand le bot transfère ;
• vers qui ;
• avec quel résumé ;
• avec quelles pièces ou données déjà collectées.

2.8 Les KPI de pilotage

Prévoyez dès le départ les indicateurs à suivre :

• volume pris en charge ;
• temps de réponse ;
• taux de résolution sur demandes simples ;
• qualité du transfert ;
• satisfaction ;
• impact commercial ou opérationnel.

2.9 Les contraintes de conformité et de sécurité

Le document doit préciser :

• les données sensibles manipulées ;
• les règles de conservation ;
• les exigences RGPD ;
• les droits d'accès ;
• les validations nécessaires côté métier et conformité.

2.10 Le mode opératoire après lancement

Un chatbot n'est pas un projet "one shot". Il faut prévoir :

• qui met à jour les contenus ;
• qui analyse les conversations ratées ;
• qui priorise les évolutions ;
• à quelle fréquence le dispositif est revu.

3. Un modèle simple à reprendre

Vous pouvez repartir de ce squelette :

# Cahier des charges chatbot
 
## 1. Objectif métier
- Quel problème voulons-nous réduire ?
- Quel parcours voulons-nous fluidifier ?
 
## 2. Public cible
- Qui utilisera le bot ?
- Dans quel contexte ?
 
## 3. Cas d'usage prioritaires
- Demande 1
- Demande 2
- Demande 3
 
## 4. Canaux
- Web
- Espace client
- Messagerie
- Téléphone
 
## 5. Sources de données
- FAQ
- Base documentaire
- CRM
- Outil métier
 
## 6. Règles conversationnelles
- Intentions à reconnaître
- Données à extraire
- Contexte à conserver
- Réponses interdites ou sensibles
 
## 7. Reprise humaine
- Quand transférer ?
- À qui ?
- Avec quel résumé ?
 
## 8. KPI
- Temps de réponse
- Taux de résolution
- Taux de transfert
- Satisfaction
 
## 9. Contraintes de conformité
- Données sensibles
- Hébergement
- Journalisation
 
## 10. Gouvernance
- Qui pilote ?
- Qui met à jour ?
- Quel rythme d'amélioration ?

4. Comment décider ensuite de la bonne solution

Une fois ce document rempli, la bonne décision devient souvent beaucoup plus claire.

• Si le besoin est simple et très borné, un assistant léger peut suffire.
• Si l'objectif est de gérer des demandes récurrentes avec transfert vers les équipes, le sujet ressemble plutôt à un Chatbot Relation Client.
• Si le besoin est d'aider à choisir et convertir, on se rapproche d'un Chatbot Vendeur Virtuel.
• Si la conversation doit lancer ou compléter un workflow administratif, il faut parfois aller vers des Agents IA Back-Office.

Le cahier des charges n'est donc pas de la paperasse. C'est l'outil qui évite de choisir la mauvaise architecture.

Conclusion

Le bon cahier des charges chatbot n'est pas un document figé. C'est un instrument de cadrage qui transforme une idée floue en projet exploitable. Plus il est précis sur le parcours, les données, le contexte, la reprise humaine et le pilotage, plus le projet a de chances d'apporter un vrai résultat métier.¹²⁴

FAQ

Faut-il détailler toute l'arborescence de conversation ?

Non. Au stade du cahier des charges, il faut surtout clarifier les cas d'usage, les informations à extraire, les sources autorisées et les règles de transfert.

Doit-on déjà choisir le modèle d'IA ?

Pas forcément. Le choix du modèle vient après le cadrage métier. Sinon, on risque de partir d'une technologie avant d'avoir défini le service attendu.

Peut-on réutiliser ce modèle pour un projet callbot ?

Oui. La structure reste pertinente, mais il faut ajouter les contraintes liées à la voix, aux temps de réponse oraux et au contexte téléphonique.