Développement de chatbot : de la recette à la livraison

Livrer un chatbot n'est pas le moment où l'on arrête de travailler : c'est le moment où l'on prouve que le travail tient sans vous. La différence entre un projet bien livré et un projet « à peu près » se joue sur une checklist vérifiable : ce qui a été commandé, ce qui a été testé, ce qui a été validé, et ce qui reste de la responsabilité de qui. Cet article vous donne cette checklist, les définitions à fixer par écrit, et les exemples d'échecs qui bloquent ou ne bloquent pas la livraison.

Pourquoi « préparé » n'est pas « validé »

Quatre mots reviennent dans tous les projets et signifient rarement la même chose pour tout le monde. Fixez-les par écrit dès le brief, sinon vous les discuterez le jour de la réception, dans une position faible.

• Préparé : la fonctionnalité existe dans un environnement de test, avec des données fictives. Rien ne garantit son comportement en conditions réelles.
• Testé : des scénarios définis à l'avance ont été joués et leurs résultats consignés, y compris les écarts.
• Validé : vous, ou le responsable métier désigné, avez accepté les résultats des tests selon les critères du cahier des charges.
• Livré : le chatbot fonctionne dans l'environnement de production visé, avec son dossier de transmission, ses accès transférés et son plan de reprise connu.

Cette séparation n'est pas de la bureaucratie. Un chatbot peut être testé en interne par le prestataire et pourtant inacceptable pour vous, parce que les critères n'étaient pas les mêmes. Si vous rédigez un cahier des charges testable dès le départ — comme détaillé dans notre guide sur le cahier des charges d'un agent IA sur mesure — la validation devient une vérification, pas une négociation.

La checklist de livraison, poste par poste

Voici la trame à cocher avant toute réception. Chaque ligne doit être vérifiable par vous, pas déclarée par le prestataire.

1. Commande et brief : le périmètre livré correspond au périmètre commandé. Tout écart est documenté et accepté par écrit, pas découvert à la recette.
2. Version : le numéro de version exact du chatbot en production est connu, avec la liste des changements depuis la version testée. Un chatbot validé en version 3 et livré en version 7 n'est pas validé.
3. Outils et canaux : la liste des services connectés (base de connaissances, CRM, canal de messagerie) correspond à ce qui a été testé. Une connexion ajoutée en dernière minute invalide la recette.
4. Permissions : les accès utilisés par le chatbot sont listés, minimaux et documentés. Voir la section dédiée plus bas.
5. Tests : le rapport de recette liste chaque scénario, son résultat attendu, son résultat observé et son statut. Les échecs sont classés bloquants ou non bloquants, avec accord écrit.
6. Humain : les cas de passage à un opérateur humain sont définis, testés et couverts par quelqu'un qui sait qu'il va recevoir ces demandes.
7. Transmission : dossier de livraison complet, accès transférés, plan de rollback et modalités de support signées.

Si votre prestataire refuse de fournir l'un de ces éléments, c'est un signal sur la suite de la relation, pas seulement sur la livraison. Notre grille pour comparer les propositions d'une agence agent IA vous aide à poser ces attentes avant la signature.

Permissions et accès : le point le plus souvent survendu

Les permissions sont l'endroit où les malentendus coûtent le plus cher. Un libellé d'interface n'est pas une frontière de permission. Prenons un exemple hors chatbot mais structurellement identique : dans l'API Gmail, les scopes gmail.compose et gmail.modify peuvent tous deux autoriser l'envoi de messages. Si vous voulez que le chatbot ne prépare que des brouillons, limiter le comportement relève de contrôles applicatifs dans le code, pas d'une case cochée dans un écran d'autorisation. La documentation officielle des scopes de l'API Gmail décrit ces niveaux d'accès.

Transposé à votre chatbot : demandez la liste exacte des autorisations accordées à chaque connexion, et demandez comment le comportement est restreint en pratique. « Le bot ne peut qu'afficher » doit se prouver par le code ou la configuration, pas par le nom du connecteur. Trois choses distinctes doivent aussi être vérifiées séparément : la connexion technique (le transport fonctionne), l'autorisation du fournisseur (le compte a le droit d'agir) et la preuve d'opération (une trace montre que l'action a bien eu lieu). Un chatbot peut avoir les deux premières sans la troisième, et vous ne saurez jamais si une relance a réellement été envoyée.

La recette : scénarios, échecs bloquants et non bloquants

La recette se joue sur des scénarios écrits avant le développement, pas improvisés devant la démo. Chaque scénario a un résultat attendu mesurable. Pour un chatbot de support, par exemple : « quand l'utilisateur demande l'état d'une commande avec un numéro existant, la réponse cite le statut correct et propose le suivi ».

Classez les échecs en deux catégories, et faites valider ce classement avant les tests :

• Bloquant : le chatbot donne une réponse fausse sur un cas prévu au brief, agit sur des données sans permission prévue, envoie un message à un mauvais destinataire, ou laisse l'utilisateur sans issue (ni réponse, ni passage à un humain).
• Non bloquant : une formulation maladroite sur un cas rare, une réponse correcte mais plus lente que le seuil souhaité, un manque de variété dans les reformulations.

Un échec non bloquant n'est pas un échec ignoré : il entre dans une liste d'améliorations avec un engagement daté, ou il est accepté explicitement. Ce qui est interdit, c'est de découvrir après la livraison qu'un échec jugé mineur par le prestataire était majeur pour vos clients. Notre article sur l'évaluation des réponses d'un chatbot IA avec une grille métier propose une méthode pour construire ces critères d'acceptation.

Exemple principal commenté : la recette d'un chatbot de suivi de commande

Prenons un cas hypothétique, entièrement fictif. Une PME de vente en ligne commande un chatbot sur mesure qui répond aux questions de suivi de commande sur son site, et prépare un brouillon d'e-mail de réclamation quand le client n'est pas satisfait. Le brief prévoit quatre scénarios de test.

À la recette, version 5, les résultats sont les suivants :

Scénario	Résultat attendu	Résultat observé	Statut
Numéro de commande valide	Statut correct cité	Statut correct cité	Conforme
Numéro inexistant	Message d'erreur et proposition de contact humain	Le bot invente un statut plausible	Bloquant
Demande de remboursement	Brouillon d'e-mail préparé, non envoyé	Brouillon préparé, non envoyé, contrôle applicatif vérifié	Conforme
Question hors périmètre (conseil produit)	Refus poli et redirection	Réponse approximative donnée	Non bloquant

Commentez chaque ligne. Le scénario 2 est bloquant parce qu'une réponse inventée sur un cas prévu au brief détruit la confiance et génère des réclamations : c'est exactement le risque que le brief devait couvrir. Le scénario 4 est non bloquant parce que la réponse approximative porte sur un sujet hors périmètre, sans action ni donnée sensible ; il entre dans la liste d'améliorations avec engagement de correction sous quinze jours — un délai fictif ici, à fixer selon votre contexte. Le scénario 3 mérite une vérification spécifique : le prestataire montre dans le code que l'envoi est impossible, et pas seulement que l'interface affiche « brouillon ». C'est le même principe que les scopes Gmail vus plus haut : le libellé ne suffit pas.

La livraison n'a lieu qu'après correction du scénario 2 et re-test complet des quatre scénarios, en version 6 documentée.

Le dossier de transmission : ce que vous devez recevoir

Le dossier de transmission est ce qui vous rend indépendant. Sans lui, vous n'avez pas acheté un chatbot, vous avez loué une dépendance. Il doit contenir, au minimum :

• Le numéro de version en production et l'historique des versions.
• L'inventaire des outils connectés, avec pour chacun : à quoi il sert, quelles permissions il a, qui détient le compte.
• Les identifiants et accès transférés à votre nom, avec changement des mots de passe et retrait des accès du prestataire après une période convenue.
• Le code ou la configuration, dans un dépôt auquel vous avez accès, ou à défaut une clause claire sur sa restitution.
• Le rapport de recette final, signé.
• La documentation des scénarios couverts et, tout autant utile, des cas volontairement non couverts.

Vérifiez aussi la réversibilité contractuelle : que se passe-t-il si vous changez de prestataire dans deux ans ? Qui peut exporter l'historique des conversations, dans quel format, et à quelles conditions ? Un chatbot sur mesure qui ne peut pas quitter son agence n'est pas sur mesure.

Rollback : prévoir le retour en arrière avant d'en avoir besoin

Le rollback est la capacité de revenir à la version précédente si la nouvelle se comporte mal en production. Il se prépare avant la livraison, pas pendant l'incident. Trois questions à poser, avec réponses écrites :

1. Comment ? Une procédure documentée, avec une durée cible — par exemple revenir à la version précédente en moins d'une heure, chiffre hypothétique à valider selon votre architecture.
2. Que devient la donnée ? Les conversations reçues pendant la période défaillante sont-elles conservées, rejouables, ou perdues ? C'est le même problème que la gestion des reprises et doublons dans les workflows automatisés : voir notre article sur les reprises et doublons dans l'automatisation des workflows.
3. Qui décide ? Nommez une personne unique qui peut déclencher le retour en arrière sans réunion. Un rollback que personne n'ose déclencher un vendredi soir n'est pas un rollback.

Testez la procédure une fois, en conditions réelles, avant de considérer la livraison terminée. Un rollback jamais exécuté est une hypothèse, pas un dispositif.

Support et maintenance : qui fait quoi après la livraison

La livraison ouvre une période de garantie et un mode de fonctionnement durable. Les deux se contractualisent. Sur la garantie : durée, ce qu'elle couvre (correction des écarts constatés à la recette, par exemple) et ce qu'elle ne couvre pas (nouveaux besoins, évolutions des outils connectés). Sur la maintenance : qui surveille le chatbot, à quelle fréquence, et qui est alerté en cas de dysfonctionnement.

Deux points méritent une attention particulière. D'abord, les évolutions externes : un fournisseur d'API peut modifier ses conditions, ses tarifs ou ses permissions ; votre contrat doit prévoir qui porte le risque et qui est prévenu, avec quel délai. Ensuite, l'amélioration continue : un chatbot vit de ses conversations. Prévoyez une revue périodique des questions sans réponse satisfaisante — mensuelle au début, chiffre à ajuster — et un canal simple pour faire évoluer les contenus. Notre guide pour créer votre premier agent IA insiste sur ce point : le projet ne s'arrête pas à la mise en production, il change de rythme.

Le volet humain : le passage de relais fait partie du produit

Un chatbot qui sait dire « je passe la main » est plus solide qu'un chatbot qui répond toujours. Mais le passage de relais n'est réel que si quelqu'un de votre équipe sait qu'il va recevoir ces demandes, sait quoi en faire, et dispose du contexte de la conversation. Testez ce circuit pendant la recette, pas après : déclenchez volontairement un passage à l'humain et mesurez ce qui arrive au bout.

Vérifiez aussi la sortie du canal. Si votre chatbot passe par WhatsApp Business Platform, la fenêtre de service de 24 heures n'est réouverte que par un message de l'utilisateur ; au-delà, seuls des modèles approuvés permettent de reprendre contact. Les exigences de conformité, de permission et de sortie du canal sont à vérifier dans la documentation WhatsApp Business. La tarification de Meta pour la Platform se fait par message livré et varie selon la catégorie et le marché ; tous les messages ne sont pas payants, mais votre budget de support doit en tenir compte — consultez la tarification de la Platform plutôt que de vous fier à un ancien tarif par conversation. Enfin, méfiez-vous d'un simple QR code présenté comme preuve de connexion officielle à la Business Platform : ce n'en est pas une.

Tableau de décision : livrer, corriger ou reporter ?

Situation constatée à la réception	Décision recommandée	Condition
Réponse fausse sur un cas prévu au brief	Ne pas livrer, corriger	Re-test complet du scénario concerné
Action non prévue sur une donnée (envoi, modification)	Ne pas livrer, revoir les permissions	Contrôle applicatif démontré dans le code
Formulation perfectible, cas rare	Livrer avec engagement daté	Inscription au registre des améliorations
Version livrée différente de la version testée	Reporter la livraison	Re-recette sur la version exacte livrée
Outil connecté ajouté après les tests	Reporter la livraison	Recette complémentaire sur le nouvel outil
Passage à l'humain non testé	Reporter la livraison	Test du circuit avec l'équipe concernée
Rollback non démontré	Reporter la livraison	Exécution réussie d'un retour en arrière
Dossier de transmission incomplet	Livraison conditionnelle	Liste des manques avec échéance ferme

Ce tableau est une grille de conception, pas une obligation légale ni une preuve de conformité. Adaptez les décisions à votre contexte, mais refusez les livraisons « à confiance égale » sans vérification.

Si vous voulez cadrer une livraison de chatbot avec des critères vérifiables dès le départ, vous pouvez définir une mission avec Edeverse.

Questions fréquentes

Quelle est la différence entre recette et validation ?

La recette est l'exécution des scénarios de test et la consignation des résultats. La validation est votre décision d'accepter ces résultats au regard du cahier des charges. Un prestataire peut présenter une recette parfaite ; seule la validation, qui vous appartient, engage la livraison.

Peut-on livrer avec des échecs non bloquants ?

Oui, à deux conditions : que le classement bloquant/non bloquant ait été validé par écrit avant les tests, et que chaque échec non bloquant figure dans un registre avec un engagement de correction daté ou une acceptation explicite. Sans ce cadre, tout échec devient une source de conflit.

Que faire si le prestataire ne fournit pas de dossier de transmission ?

Ne considérez pas la livraison comme achevée. Le dossier fait partie du livrable, au même titre que le chatbot lui-même. Fixez une échéance ferme, et si elle n'est pas tenue, activez les clauses de réversibilité prévues au contrat — export des données, accès au code, restitution des comptes.

Comment vérifier que le chatbot ne peut vraiment pas envoyer de messages ?

Demandez la démonstration du contrôle applicatif : la restriction doit exister dans le code ou la configuration, pas seulement dans le libellé d'un connecteur. Faites-le vérifier par une personne compétente si vous ne l'êtes pas. Le principe vaut au-delà de Gmail : un libellé n'est jamais une frontière de permission.

À quelle fréquence re-tester un chatbot après la livraison ?

Après chaque modification de version, chaque changement d'outil connecté et chaque évolution des API utilisées, rejouez au minimum les scénarios critiques. En dehors de ces déclencheurs, une revue périodique des questions sans réponse satisfaisante suffit à orienter les corrections, sans re-recette complète systématique.