Passer au contenu principal

Checklist de lancement

Utilisez cette checklist avant de présenter ChattyBox à vos clients. Elle détecte les lacunes courantes de configuration qui donnent l’impression qu’un chatbot est installé alors qu’il n’est pas prêt.

Pour un déploiement de support, associez cette checklist au guide du chatbot IA pour le support client afin que les réponses issues du contenu public aient un parcours d’escalade clair pour les questions propres au compte, sensibles ou non résolues.

Préparation du contenu​

  • Des contenus publics et accessibles au crawler ont été sélectionnés pour servir de sources au chatbot.
  • Les pages privées, d’administration, de paiement, de compte, les brouillons et le staging sont exclues par sélection explicite des sources, pas seulement via robots.txt (que le crawler ne respecte pas). Cette sélection ne remplace pas les contrôles d’accès de votre site.
  • Vous avez choisi la bonne source : sitemap, URL manuelles, page d’accueil seule ou crawl. Le crawl utilise d’abord les sitemaps conventionnels détectés, puis les liens ; il ne complète pas un sitemap incomplet en suivant des liens.
  • Les pages importantes consacrées au produit, aux tarifs, aux politiques, au support, à la FAQ, à l’onboarding et au dépannage sont incluses.
  • Les sites multilingues incluent les versions linguistiques à partir desquelles vous souhaitez que le widget réponde.

Validation du scraping​

  • Le scraping est terminé, les nombres de pages sélectionnées/enregistrées ont été comparés et les pages attendues sont présentes. Le statut Terminé ne garantit pas que toutes les URL ont abouti ni que le contenu est prêt pour les réponses.
  • Le nombre de pages indexées correspond à ce qui était prévu pour votre formule et le périmètre du lancement.
  • Les pages Partiellement indexé ont été vérifiées pour repérer le texte tronqué au-delà de la limite de 512 KiB ; les longues pages ont été divisées si nécessaire.
  • Le traitement séparé des embeddings est terminé et des recherches représentatives ont été testées.
  • Les pages récemment modifiées ou migrées ont fait l’objet d’un nouveau scraping.
  • Les pages manquantes ont été vérifiées pour l’authentification, les défis anti-bot, les redirections échouées ou non sûres, les filtres de sources et le contenu uniquement JavaScript. Le texte important est présent dans le HTML récupéré sans rendu JavaScript.
  • Les pages obsolètes déjà enregistrées ont été supprimées de Base de connaissances → Pages, pas seulement retirées du sitemap, et les sources ont été ajustées pour empêcher leur redécouverte.

Utilisation et accès​

  • Le propriétaire du projet peut accéder au tableau de bord et gérer le chatbot ; les clés publiques et l’appartenance à une organisation ne confèrent pas les droits du propriétaire dans le tableau de bord.
  • Dans Facturation et utilisation (/settings/account), le quota de messages couvre les tests et le trafic de lancement pour l’ensemble des chatbots du propriétaire. Tester le chatbot consomme aussi ce quota.
  • Les limites de pages enregistrées et le budget mensuel distinct d’actualisation des pages ont été vérifiés. Ce budget est partagé entre les projets du propriétaire du compte. Les reconstructions manuelles de l’index consomment aussi ce budget et ont leur propre délai d’attente selon la formule.
  • Le calendrier d’actualisation est compatible avec la formule : Free au plus une fois par semaine, les formules payantes au plus une fois par jour. Les nouvelles tentatives manuelles de scraping attendent au moins 7 jours (Free) ou 24 heures (formules payantes) après la création du job le plus récent, même si celui-ci a échoué.
  • Pour Pro/Business, le PAYG (facturation à l’usage) est désactivé par défaut ; plafonnez-le par fonctionnalité ou choisissez volontairement Aucun plafond de dépense, qui peut entraîner des frais sans limite. Il ne supprime ni le délai d’actualisation du crawler ni le budget mensuel.
  • Si le verrouillage de configuration est utilisé, ses restrictions irréversibles et le processus distinct de déploiement avec jeton secret sont compris.

Qualité des réponses​

  • Vous avez posé de vraies questions de test issues de cas d’utilisation commerciaux, de support, d’onboarding et de documentation.
  • Les réponses représentatives s’appuient sur le contenu indexé et les questions non couvertes reçoivent le fallback prévu. Vérifiez les réponses : un test réussi ne garantit pas l’exactitude de toutes les réponses futures.
  • Des citations de sources apparaissent dans les réponses utiles.
  • Les liens de citation ouvrent les pages sources publiques attendues.
  • Les réponses faibles ont été corrigées en améliorant le contenu source ou en ajoutant les pages manquantes, puis un nouveau scraping a été effectué.
  • Si la Persona a été modifiée, vérifiez que le statut d’enregistrement confirme sa sauvegarde ; corrigez les erreurs de validation ou réessayez l’enregistrement en cas d’échec avant de tester le fallback. Testez séparément le fallback imposé ; le texte de la Persona ne remplace pas la réponse configurée lorsque le contexte manque.
  • Les questions de test incluent le contexte nécessaire : pour une même conversation, le générateur reçoit au plus 12 des messages enregistrés les plus récents, limités chacun à 2 000 caractères, et non l’historique complet.

Installation du widget​

  • Le widget est installé sur les pages publiques prévues.
  • Le script n’est chargé qu’une fois par page.
  • Le script contient data-api-key.
  • Le script contient data-api-url.
  • Détection automatique / Fixe et Autoriser le remplacement par script sont définis intentionnellement. data-locale ne prend le dessus que si les remplacements sont autorisés, même en mode Fixe.
  • La langue de l’interface du widget, celle des questions/réponses et les versions linguistiques indexées ont été testées séparément.
  • Le widget s’ouvre et envoie une question de test dans une fenêtre privée.
  • Les tests sur viewport mobile confirment que le launcher et le panneau de chat sont utilisables.

Vérifications de la clé API et des restrictions d’origine facultatives​

  • La clé publique prévue est sélectionnée dans Installer → Installation sur le site web ; ses paramètres se gèrent dans Clés et domaines.
  • Toute rotation a été effectuée en installant et en testant la nouvelle clé avant de supprimer l’ancienne. Le nom d’une clé ne restreint pas son environnement.
  • La clé publique a été testée sur les sites de production, de prévisualisation/staging et localhost prévus. Vérifiez ses restrictions : une clé préparée pour un site peut déjà être restreinte à cette origine ; les clés créées sans restriction fonctionnent depuis toutes les origines du navigateur.
  • Si le renforcement facultatif est activé, Clés et domaines → Modifier les origines contient les origines exactes prévues (schéma, nom d’hôte et port). Une restriction d’origine n’authentifie pas les visiteurs ; les clés publiques de navigateur ne sont pas des secrets.
  • Aucune clé API privée de serveur, aucun jeton d’administration ni aucun secret ne figure dans le code frontend, GTM, le HTML personnalisé du CMS ou le code source de la page.

Vérifications du navigateur et du déploiement​

  • La console du navigateur ne contient aucune erreur ChattyBox.
  • La Content Security Policy autorise le script du widget et l’URL de l’API si votre site utilise une CSP.
  • Les bloqueurs de publicité ou les outils de consentement ne bloquent pas le widget sur les pages où il est attendu.
  • Le site final déployé, et pas uniquement le développement local, a été testé.

Après le lancement​

  • Consultez Conversations → Historique sur toute formule, puis Analyses / Questions sans réponse sur Pro/Business.
  • Interprétez Analyses comme un maximum de 5 000 interactions enregistrées sur les 30 derniers jours, tests du chatbot inclus ; elles ne prouvent ni l’exactitude des réponses ni un trafic provenant uniquement des visiteurs.
  • Examinez les lacunes détectées, retestez le contenu amélioré et résolvez-les manuellement. La liste par défaut masque les lacunes résolues ; Inclure les lacunes résolues et Annuler permettent de les afficher et de les rouvrir. Une réapparition ne rouvre pas automatiquement une lacune résolue.
  • Si l’attribution par page est importante, vérifiez Déclencheurs populaires. Le widget hébergé envoie le contexte de la page et conserve son chemin, mais pas ses paramètres de requête ni son fragment. Évitez de charger ou de laisser le widget actif sur des routes sensibles/privées. Dans une SPA, exclure une route du déclencheur initial ne retire pas un widget déjà initialisé : démontez-le explicitement. Le SDK headless sendMessage() n’envoie pas le contexte de la page source.
  • Ajoutez la documentation, les FAQ ou les exemples manquants en fonction des questions réelles des visiteurs.
  • Relancez le scraping des pages mises à jour après les changements de contenu, lorsque le délai et le budget d’actualisation le permettent.
  • Faites tourner les clés publiques du widget si nécessaire ; ne mettez à jour les restrictions d’origine que si elles sont activées et que les domaines autorisés changent.
  • La suppression d’une conversation ne réinitialise pas l’utilisation et n’efface pas les enregistrements d’analyses ; ces données sont distinctes.

Si un élément échoue, utilisez le Dépannage avant le lancement.