Cahier des charges d'un chatbot WhatsApp : un modèle à copier, avec les questions à poser au prestataire

Cahier des charges d'un chatbot WhatsApp : un modèle à copier, avec les questions à poser au prestataire

Ce que vous n'écrivez pas avant le lancement, quelqu'un le décidera à votre place après.

Réponse courte. Un chatbot WhatsApp se cadre en dix rubriques : périmètre et cas d'usage, parcours et passage à un humain, base de connaissances, langues et ton, mesure, sécurité et données personnelles, modèles de message, tests, exploitation et responsabilité, recette. Pour chacune, cet article donne un texte à copier avec des blancs à remplir, les questions à poser au prestataire et les réponses qui doivent vous alerter. Ce modèle est notre proposition de structure, pas une norme : nous n'en avons trouvé aucune à citer. Les exigences qui s'appuient sur une source relue renvoient à elle ; les autres portent la mention « notre recommandation ». Pour les trois risques de fond (ce que dit le bot vous engage, la plateforme du bot est une surface d'attaque, le canal appartient à Meta), nous renvoyons à notre article sur la responsabilité du chatbot plutôt que de le répéter.

Transparence. BOVO Digital est une agence basée au Bénin qui construit des chatbots WhatsApp : nous sommes donc intéressés par le sujet, et un cahier des charges précis nous oblige aussi. Cet article ne repose sur aucune donnée, aucun client, aucun prix et aucun résultat de BOVO. Il ne constitue pas un conseil juridique. Les sources ont été rouvertes le 7 novembre 2026 avec un outil de lecture de pages qui renvoie un texte traité et non le HTML brut : les citations ci-dessous sont celles qu'il a restituées. Ce qui relève de notre raisonnement est signalé comme « notre recommandation ».

Comment utiliser ce modèle

Chaque rubrique suit le même ordre : un bloc À écrire que vous copiez et complétez, des Questions au prestataire, et des Réponses qui doivent alerter. Les crochets [ ] sont des blancs. Si une rubrique ne s'applique pas à votre projet, écrivez « sans objet » et pourquoi : un blanc laissé vide se lit ensuite de la façon que chacun préfère.

Deux limites. Le modèle ne chiffre rien : les prix, délais et volumes dépendent de votre cas, et nous ne donnons ici aucun montant (pour un ordre de grandeur, voir le prix d'un chatbot IA sur mesure). Et il suppose un chatbot qui peut utiliser un modèle de langage ; si le vôtre suit un arbre de décision fixe, certaines rubriques (base de connaissances, injection de prompt) deviennent plus simples.

1. Périmètre et cas d'usage

À écrire.

Objectif du chatbot : [une phrase]
Cas d'usage traités (3 à 5 maximum au lancement) :
  1. [ex. suivre une commande]   2. [ex. prendre un rendez-vous]   3. [ex. répondre à la FAQ]
Sujets refusés explicitement : [ex. remboursements, litiges, conseils juridiques, questions hors activité]
Réponse du bot à un sujet refusé : [texte exact] puis renvoi vers [personne / canal]
Actions que le bot peut déclencher dans nos systèmes : [liste] ; toutes les autres sont interdites
Public visé : [clients existants / prospects] ; pays : [ ]

Pourquoi. Notre recommandation : un périmètre écrit est la base de tous les tests de la rubrique 8. Pour les actions, l'OWASP (Top 10 pour les applications LLM, édition 2025, risque LLM06 « Excessive Agency ») recommande de limiter les extensions, leurs fonctions et leurs permissions « au minimum nécessaire » : page LLM06. Les engagements que le bot ne doit pas prendre (prix, remboursement, délai) sont traités dans notre article sur Air Canada et McHire.

Questions au prestataire.

• Quelles sont les actions techniques que le bot peut effectuer sur nos systèmes, avec quelles permissions ?
• Que se passe-t-il quand un client demande quelque chose hors périmètre ?
• Pouvez-vous nous montrer la liste des refus avant le développement ?

Réponses qui doivent alerter. « Le bot répond à tout » ; un accès administrateur complet à votre CRM ou à votre base « pour simplifier » ; aucune liste de sujets refusés.

2. Parcours et passage à un humain

À écrire.

Premier message : annonce que c'est un bot, ce qu'il sait faire, comment joindre une personne
Menu ou texte libre : [ ]
Déclencheurs du passage à un humain : demande explicite du client ; [n] échecs de compréhension de suite ; sujet refusé ; client mécontent ; [ ]
Qui reçoit : [personne / équipe] ; horaires : [ ] ; délai de reprise visé : [ ]
Ce qui est transmis : historique complet de la conversation, numéro, motif
Hors horaires : message au client avec [délai annoncé] et [alternative]
Actions à validation humaine avant exécution : [ex. remise, annulation, modification de commande]

Sources. L'OWASP recommande, contre l'injection de prompt, d'« exiger une validation humaine pour les actions à haut risque » (LLM01), et, pour l'agentivité excessive, un contrôle humain pour les actions à fort impact (LLM06). Contrainte WhatsApp, lue dans la documentation de tarification de Meta : quand la fenêtre de service de 24 heures est fermée, l'entreprise ne peut envoyer que des messages modèles. Si un humain doit relancer un client après un long délai, il faut donc un modèle approuvé (rubrique 7). Le reste (déclencheurs, délai de reprise, message hors horaires) est notre recommandation.

Questions au prestataire.

• Comment le client demande-t-il une personne, et en combien de messages ?
• L'agent humain voit-il l'historique, dans quel outil ?
• Que se passe-t-il si personne ne répond, ou si la fenêtre de 24 heures est fermée ?

Réponses qui doivent alerter. « Le passage à un humain viendra dans une phase 2 » ; un transfert sans historique ; aucune règle pour les conversations qui tournent en boucle.

3. Base de connaissances et sources de vérité

À écrire.

Documents sources : [liste : catalogue, conditions de vente, FAQ, procédures] avec responsable et date de dernière mise à jour
Source de vérité en cas de conflit : [document X]
Le bot répond uniquement à partir de ces documents : oui / non ; sinon, dit « je ne sais pas » et propose un humain
Questions sensibles (prix, garanties, délais, remboursements) : réponse citée mot pour mot depuis [document], ou renvoi humain
Mise à jour : qui, à quelle fréquence, comment est vérifié que le bot a pris la modification en compte
Mention de transparence dans le bot : « Je suis un assistant automatique. En cas de doute, [source qui fait foi]. »

Sources. L'OWASP (risque LLM09 « Misinformation », page) liste parmi ses mesures la génération augmentée par récupération (ancrer les réponses dans des informations vérifiées), la supervision humaine et la vérification pour les informations critiques, la communication des risques et limites aux utilisateurs, et l'étiquetage des contenus générés par IA. La désignation d'un responsable et d'une date de mise à jour par document est notre recommandation. Sur les hallucinations en entreprise : notre guide.

Questions au prestataire.

• Le bot cite-t-il le document d'où vient sa réponse ? Pouvons-nous le voir dans les journaux ?
• Que répond-il quand l'information n'est pas dans la base ?
• Comment une modification de nos tarifs se retrouve-t-elle dans le bot, et en combien de temps ?

Réponses qui doivent alerter. « Le modèle connaît déjà votre secteur » sans base fournie par vous ; aucune façon de voir la source d'une réponse ; mise à jour « sur demande, par ticket » sans délai.

4. Langues et ton

Cette rubrique n'a pas de source : tout ce qui suit est notre recommandation.

À écrire.

Langues acceptées en entrée : [français, anglais, autres] ; langue de réponse : [même langue que le client / français]
Cas non pris en charge : [ex. messages vocaux, images] → réponse type : [texte]
Ton : [vouvoiement / tutoiement], longueur maximale d'une réponse : [n] lignes, emojis : [oui / non]
Mots et formulations interdits : [ex. promesse de délai, « je garantis »]
Exemples de 10 messages réels de vos clients (fautes d'orthographe, mélange de langues compris) pour les tests

Le point à ne pas négliger : exigez que le jeu de tests de la rubrique 8 contienne des messages écrits comme vos clients écrivent vraiment. Nous ne savons pas quel niveau de qualité un modèle donné atteint dans les langues locales que vous utilisez ; seul un test sur vos messages vous le dira.

Questions au prestataire. Sur quels messages réels de nos clients avez-vous testé ? Comment le bot réagit-il à un vocal ou à une photo ?

Réponses qui doivent alerter. « Il comprend toutes les langues » sans test montré ; des tests faits uniquement sur des phrases rédigées par l'équipe du prestataire.

5. Mesure : définitions posées avant le lancement

À écrire.

Conversation : [définition : suite de messages d'un même client sans silence de plus de N heures]
Conversation « résolue » : [définition écrite, ex. le client a obtenu la réponse ou l'action demandée ET n'a pas rouvert le même sujet sous N jours ET n'a pas été transféré à un humain]
Conversation « abandonnée » : [définition écrite, ex. le client cesse de répondre alors que le bot attendait une réponse, avant d'avoir obtenu l'action ou la réponse]
Transfert à un humain : compté séparément, ni résolu ni abandonné
Qui qualifie : [calcul automatique / relecture manuelle d'un échantillon de n conversations par mois]
Période de mesure et jours exclus : [ ]
Indicateurs au lancement : volume, taux de transfert, taux de résolution, taux d'abandon, [satisfaction]
Seuils d'alerte : [ex. si le taux de transfert dépasse X, revue sous 48 h]

Pourquoi. Notre recommandation, avec une raison documentée : les chiffres de résolution publiés par les fournisseurs sont difficiles à comparer, comme le montre notre lecture critique de Capitec (la page source ne définit pas « résolu ») et notre article sur les chiffres de Rawbank, Twiga et NDoH. Les valeurs d'exemple entre crochets sont à vous de choisir ; nous ne proposons pas de seuil « normal ».

Questions au prestataire.

• Comment votre outil sait-il qu'une conversation est résolue ? Peut-on relire un échantillon pour vérifier ?
• Une conversation transférée à un humain puis réglée compte-t-elle comme résolue par le bot ?
• Aurons-nous un accès direct aux journaux, ou seulement à un tableau de bord que vous contrôlez ?

Réponses qui doivent alerter. Un taux de résolution annoncé avant d'avoir défini le mot ; un « taux de satisfaction » sans méthode ; un tableau de bord sans accès aux conversations sous-jacentes.

6. Sécurité et données personnelles

À écrire.

Données collectées par le bot : [liste] ; finalité de chacune : [ ] ; données interdites dans le chat : [ex. pièce d'identité, identifiants bancaires]
Lieu de stockage des conversations : [pays / hébergeur] ; qui y a accès : [noms ou rôles] ; accès journalisés : oui / non
Durée de conservation fixée à l'avance : [n mois] ; suppression automatique : oui / non ; procédure de suppression à la demande d'un client : [ ]
Secrets (jetons, clés d'API) : stockés dans [coffre / variables d'environnement], jamais dans le texte d'instruction du bot, jamais transmis au modèle
Comptes : mots de passe uniques, double authentification, pas de compte de test en production ; inventaire des accès tous les [3] mois
Signalement d'incident : contact sécurité [adresse] ; délai maximal de notification au client : [heures]
Sous-traitants et pays d'où le prestataire accède aux données : [liste]
Consentement : [texte d'opt-in qui nomme l'entreprise], preuve conservée : [où]

Sources.

• Minimiser et limiter la durée. Le RGPD, article 5, demande des données « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités » et une conservation limitée dans le temps (texte du chapitre II sur le site de la CNIL, points c et e). La page de la CNIL sur les durées de conservation (datée du 2 avril 2026) précise que le responsable de traitement détermine la durée en fonction de la finalité. Le RGPD s'applique si vous traitez des données de personnes dans l'UE ; pour le Bénin, voir notre article sur le Code du numérique, qui rappelle que nous ne tranchons pas le droit local.
• Secrets et accès. L'OWASP recommande de garder les jetons d'API et les fonctions sensibles « dans le code applicatif » plutôt que de les donner au modèle, et de limiter le modèle à l'accès nécessaire (LLM01). Pour la divulgation d'informations sensibles (LLM02), il recommande des contrôles d'accès stricts au moindre privilège, de limiter les sources de données accessibles au modèle, d'informer les utilisateurs de ne pas saisir d'informations sensibles et d'avoir des politiques claires de conservation et de suppression.
• Consentement. La documentation de Meta écrit que l'entreprise doit « clairement » nommer l'entreprise auprès de laquelle la personne s'inscrit, que le consentement peut être général et non spécifique à WhatsApp « tant que les entreprises respectent toutes les lois locales », et que Meta limite le débit d'envoi d'une entreprise dont la qualité est basse sur la durée. Détails : notre article sur l'opt-in.
• Prestataire hors UE. Voir la checklist RGPD pour un prestataire hors UE, à joindre au contrat.
• Les délais de notification, la fréquence d'inventaire des accès et la liste « données interdites dans le chat » sont notre recommandation.

Questions au prestataire.

• Où sont les conversations, qui peut les lire, et comment les accès sont-ils tracés ?
• Quelles données transitent par le modèle de langage et chez quel fournisseur ?
• Existe-t-il un contact pour signaler une faille ? Quel délai pour nous prévenir d'un incident ?
• Que devenons-nous des données à la fin du contrat ?

Réponses qui doivent alerter. « Nous gardons tout, au cas où » ; un compte administrateur partagé entre plusieurs personnes ; aucune réponse écrite sur le pays d'hébergement ; une clé d'API collée dans le texte d'instruction du bot.

7. Modèles de message, catégories et règles de la plateforme

À écrire.

Numéro WhatsApp : [propriétaire du compte : NOTRE entreprise] ; compte Meta Business au nom de : [ ]
Messages libres : uniquement dans la fenêtre de 24 h après un message du client
Modèles à créer avant le lancement :
  nom (minuscules, chiffres, underscores)  | catégorie (marketing / utilitaire / authentification) | cas d'usage | texte | variables
  [ ]                                       | [ ]                                                      | [ ]         | [ ]   | [ ]
Responsable de la soumission et du suivi des statuts : [ ]
Messages envoyés sans demande du client : seulement avec opt-in documenté, avec moyen de se désabonner
Coût mensuel estimé des messages et qui le paie : [ ]
Plan B si le canal est suspendu : [courriel / SMS / formulaire]

Sources. Lues dans la documentation de Meta (pages relues le 7 novembre 2026) :

• Trois catégories de modèles : marketing, utilitaire, authentification (tarification). « Chaque modèle doit être classé » dans l'une des trois, et les catégories « jouent aussi sur le prix » (consignes sur les modèles).
• Les modèles peuvent être envoyés à tout moment ; les messages hors modèle ne répondent qu'à un utilisateur, dans la fenêtre de 24 heures qui se relance à chaque message (tarification).
• La facturation se fait par message délivré depuis le 1er juillet 2025 (même page). Pour les changements d'octobre 2026, voir notre article sur la fenêtre de 24 h et la facturation ; nous ne reprenons pas de montant ici.
• Un modèle est revu automatiquement à la création ou après modification, et la revue « peut prendre jusqu'à 24 heures » ; le nom est limité aux minuscules, chiffres et underscores ; les changements de statut arrivent par le webhook message_template_status_update (consignes).
• Le propriétaire du compte et le plan B sont notre recommandation : nous n'avons pas relu de page de Meta sur la propriété des comptes.

Questions au prestataire.

• Le compte WhatsApp Business et le compte Meta sont-ils à notre nom, avec nous comme administrateur ?
• Qui rédige les modèles, dans quelle catégorie les rangez-vous, et que faites-vous si Meta en refuse un ?
• Comment êtes-vous alerté d'un changement de statut ?

Réponses qui doivent alerter. Un numéro et un compte enregistrés au nom du prestataire ; des relances marketing classées en « utilitaire » pour payer moins ; aucun suivi des refus de modèles.

8. Tests et jeu d'évaluation

À écrire.

Jeu d'évaluation (fourni par nous, caché au prestataire pour une partie) :
  - [30] questions courantes réelles de nos clients, avec la réponse attendue et la source
  - [10] questions hors périmètre, réponse attendue : refus poli + renvoi
  - [10] questions pièges sur les prix, délais et remboursements : réponse attendue = texte cité ou humain
  - [10] tentatives de détournement : « ignore tes instructions », demande du texte d'instruction, demande de données d'autres clients
  - [10] messages mal écrits, mélangés, vocaux, images
Critère d'acceptation : [ex. 0 promesse fausse sur les sujets sensibles ; X % de réponses correctes sur les questions courantes ; 100 % de refus sur les tentatives de détournement]
Rejeu du jeu complet : à chaque changement de modèle, de base de connaissances ou d'instructions
Relecture humaine d'un échantillon de [n] conversations réelles par semaine pendant [4] semaines après le lancement

Sources. L'OWASP recommande des tests adverses et des simulations d'attaque réguliers, en traitant le modèle comme un utilisateur non fiable (LLM01), et des mécanismes de validation automatique des sorties clés (LLM09). Les effectifs du jeu, les seuils et le rejeu à chaque changement sont notre recommandation : les nombres entre crochets sont des points de départ à ajuster, pas des normes.

Questions au prestataire.

• Quel jeu de tests utilisez-vous, et pouvons-nous y ajouter les nôtres ?
• Les résultats sont-ils livrés par cas, pas seulement en pourcentage global ?
• Que se passe-t-il quand le fournisseur du modèle change sa version ?

Réponses qui doivent alerter. « On a testé, ça marche » sans cas écrits ; un pourcentage unique sans liste des échecs ; aucun test de détournement ; promesse de « zéro erreur ».

9. Exploitation et responsabilité

À écrire.

Bouton d'arrêt : coupure du bot en [minutes] par [qui] ; message affiché aux clients pendant l'arrêt : [ ]
Supervision : alertes si [taux de transfert / erreurs d'envoi / refus de modèles] dépassent [seuil], envoyées à [personne]
Journaux : conversations, dates, version du bot et de la base de connaissances conservées [durée] ; accessibles à nous sans délai
Correction d'une réponse fausse signalée : accusé sous [délai], correction sous [délai], rejeu du jeu de tests
Revue mensuelle : échantillon de conversations, indicateurs de la rubrique 5, modèles de message refusés
Responsabilités : le prestataire répond de [anomalies du bot par rapport au cahier des charges] ; nous répondons de [contenu de la base de connaissances, validité des informations fournies] ; ce qui est hors de contrôle de chacun : [changements de règles de Meta, panne du fournisseur du modèle]
Fin de contrat : export des conversations, des modèles, de la configuration ; suppression certifiée chez le prestataire
Propriété du code et des configurations : [cession écrite / licence]

Sources. Nous n'avons pas de source externe pour le partage de responsabilités entre vous et le prestataire : c'est notre recommandation, et un juriste doit relire la clause. Le principe de départ vient du cas Air Canada, détaillé dans notre article : le tribunal a jugé l'entreprise responsable de ce que disait son chatbot, dans une décision canadienne qui ne dit rien du droit béninois ou français. Pour la propriété du code, voir qui possède le code. La supervision humaine continue est aussi une mesure de l'OWASP contre la désinformation (LLM09).

Questions au prestataire.

• Combien de temps pour couper le bot si une réponse pose problème, et qui peut le faire ?
• Qui nous prévient quand Meta change une règle ou un tarif ?
• Que recevons-nous si nous arrêtons le contrat ?

Réponses qui doivent alerter. Une clause qui met toute responsabilité sur vous « du fait de l'IA » ; un arrêt qui passe par un ticket sans délai ; aucune sortie de vos données en fin de contrat.

10. Recette et acceptation

À écrire.

Livrables : [bot configuré, base de connaissances, modèles approuvés, journaux accessibles, documentation d'exploitation, accès administrateur à notre nom]
Recette : exécution du jeu de la rubrique 8 devant nous ; liste des écarts signée ; corrections et nouveau passage
Période de suivi après lancement : [semaines] avec revue hebdomadaire des conversations
Paiement : jalons liés à la recette, pas seulement à la livraison
Documents annexés : cahier des charges signé, jeu de tests, définitions de la rubrique 5, réponses du prestataire aux questions des rubriques 1 à 9

Cette rubrique est notre recommandation entière. L'idée est qu'un cahier des charges sans critère de recette ne peut pas être contrôlé.

Réponses qui doivent alerter. Un prestataire qui refuse d'annexer ses réponses au contrat, ou qui propose une recette sans cas écrits.

Ce que ce modèle ne garantit pas

• Il ne garantit pas qu'un chatbot ne se trompera jamais : les mesures de l'OWASP réduisent des risques, elles ne les suppriment pas.
• Il ne remplace pas un avis juridique sur le droit béninois, français ou d'un autre pays.
• Il ne dit rien du prix : un cahier des charges plus précis peut coûter plus à construire, et nous n'avons pas de donnée indépendante pour dire de combien.

Ce que nous ne savons pas

• Nous n'avons pas trouvé de norme ni de modèle de cahier des charges de chatbot reconnu : cette structure est la nôtre, et d'autres découpages sont possibles.
• Nous n'avons relu que les pages du Top 10 OWASP pour les applications LLM citées (LLM01, LLM02, LLM06, LLM09) et la page d'index de l'édition 2025. Plusieurs descriptions sont tronquées sur la page d'index, et nous n'avons pas lu les autres risques ni les guides complémentaires.
• Nous avons lu les pages de Meta et de la CNIL avec un outil qui les restitue en texte traité. Nous n'avons pas pu comparer avec la mise en page d'origine, et nous ne savons pas si ces pages ont changé depuis le 7 novembre 2026.
• Nous n'avons pas relu les pages de Meta sur la propriété des comptes, la vérification d'entreprise ni les limites d'envoi : le modèle ne s'appuie pas dessus.
• Nous ne savons pas quel niveau de qualité atteint un modèle de langage donné dans les langues locales de vos clients : seul un test sur vos messages réels le dira.
• Nous n'avons pas de donnée indépendante sur les taux de résolution ou d'abandon qu'un chatbot de petite entreprise peut atteindre ; le modèle ne fixe donc aucun seuil.
• Nous ne savons pas comment le droit béninois traite la responsabilité partagée entre une entreprise et son prestataire de chatbot.

Sources consultées le 7 novembre 2026

• OWASP Top 10 for LLM Applications, édition 2025 : page d'index (primaire, descriptions tronquées).
• LLM01:2025 Prompt Injection : définition et mesures (primaire).
• LLM02:2025 Sensitive Information Disclosure : définition et mesures (primaire).
• LLM06:2025 Excessive Agency : définition et mesures (primaire).
• LLM09:2025 Misinformation : définition et mesures (primaire).
• Tarification de la WhatsApp Business Platform : catégories, fenêtre de 24 h, facturation par message délivré ; la page n'affiche pas de date de mise à jour (primaire).
• Obtenir l'opt-in (documentation Meta) : nom de l'entreprise, consentement général, limitation de débit (primaire).
• Consignes sur les modèles de message (documentation Meta) : catégories, revue, nom, webhook de statut (primaire).
• CNIL, les durées de conservation des données : page du 2 avril 2026 (primaire).
• CNIL, texte du RGPD, chapitre II : article 5, points c et e (primaire ; le point e est restitué de façon partielle par l'outil).

Vous voulez cadrer votre chatbot avec ce modèle, ou le faire relire avant de signer avec un prestataire ? Découvrez notre agence de chatbot WhatsApp au Bénin.