Lorsqu’un chatbot de site ne se charge pas, identifiez l’étape en échec avant de modifier les réglages : la page peut ne pas contenir son chargeur, le navigateur peut bloquer une ressource, une règle de consentement peut retarder volontairement son chargement, la configuration peut être indisponible ou une interface montée peut rester masquée. Un widget visible qui ne trouve pas de réponse relève d’un autre problème. Partez de la page, de l’état du visiteur et des observations du navigateur, puis confiez un problème précisément délimité au bon responsable.
Ce guide propose une liste originale de ressources et d’états pour évaluer un widget de chat. Il ne recommande ni de désactiver Content Security Policy, ni de copier la liste d’autorisations d’un autre fournisseur, ni de déclarer un dispositif de consentement conforme. Un diagnostic utile peut aboutir à une suspension pour incompatibilité, plutôt qu’à une consigne d’affaiblissement de la politique du site.
Auteur : Achla AI, organisation. Révision : 14 octobre 2026. Ce cadre associe la documentation actuelle des navigateurs et des fournisseurs aux instructions d’installation d’Achla examinées, avec l’aide de l’IA. Les exemples sont hypothétiques ; aucun incident client ni résultat de test navigateur n’a été mesuré. L’objectif est de rendre le problème de chargement vérifiable avant l’évaluation ou la modification du widget par le propriétaire du site.
Que manque-t-il : interface, requête ou source de réponse ?
Décrivez ce que voit réellement le visiteur. « Le chatbot est cassé » regroupe plusieurs observations qui nécessitent des responsables et des corrections différents.
En l’absence de bouton ou d’encadré intégré, examinez installation, chargement et visibilité. Si l’interface apparaît mais ne peut obtenir sa configuration ou sa réponse, examinez la requête concernée et l’état documenté du serveur. Si l’interface répond mais omet une page particulière, examinez séparément la collecte des sources et la recherche d’information.
Ne modifiez pas les permissions d’exploration pour réparer une interface absente. De même, un script chargé avec succès ne prouve pas la réussite de la requête de réponse. La documentation d’installation d’Achla distingue emplacement et vérification, tandis que ses conseils de dépannage séparent les problèmes de widget et de recherche. Commencez par la couche étayée par votre observation.
Notez la page publique exacte et l’état dans lequel le problème se produit. L’aperçu d’un éditeur connecté ne prouve pas l’expérience d’un visiteur anonyme. Précisez si la page vient d’être ouverte, est revisitée ou a été atteinte après un choix de consentement.
Suivre la matrice des ressources et des états
Utilisez cette fiche originale pour consigner des preuves plutôt que deviner une correction. Ses lignes décrivent des situations possibles, pas des mesures issues d’un incident réel.
| Étape | Preuves à consigner | Question au responsable |
|---|---|---|
| Balisage de la page | Intégration attendue présente ou absente sur la page publiée | Ce modèle ou connecteur gère-t-il les pages prévues ? |
| Chargeur | URL du script, état de la requête et message de console pertinent | Le chargeur a-t-il été demandé, bloqué ou impossible à charger ? |
| Configuration | Requête de configuration et réponse observable | A-t-elle atteint le service prévu et l’état documenté est-il prêt ? |
| Requête de réponse | Résultat de l’envoi d’une question publique de test | La requête est-elle bloquée, rejetée ou suivie d’une réponse utilisable ? |
| Interface montée | Commandes visibles et éléments masqués ou déplacés | Le widget est-il monté sans apparaître à l’endroit attendu ? |
| Séquence de consentement | Observations d’une nouvelle visite, d’un refus, d’un accord et d’un retour | Le retard est-il voulu et la séquence approuvée fonctionne-t-elle ? |
Laissez un champ inconnu tel quel. « Aucune requête observée » et « requête rejetée » sont deux constats différents. Recueillez un message de console précis ou un résultat de requête, si disponible, au lieu de traduire tout échec par « CORS ».
Ajoutez une condition d’acceptation à côté de la ligne en échec. Par exemple, « après le choix de consentement approuvé, la requête de configuration documentée atteint son service prévu » est plus utile que « faire apparaître le bot ». Pour une interface masquée, la condition peut désigner la page publiée et l’emplacement prévu de la commande. Ce sont des critères proposés, pas des vérifications achevées.
Confiez chaque ligne au responsable de sa couche. Un problème de modèle relève du mainteneur du site ; une exigence de politique contestée, du responsable sécurité ; un retard voulu, du responsable consentement. Le support fournisseur peut devoir préciser un prérequis documenté. Évitez de modifier une autre couche simplement parce que ses réglages sont plus accessibles.
Identifiez aussi le mécanisme d’intégration. Le connecteur WordPress et le module Drupal d’Achla utilisent leur propre chargeur, plutôt qu’une balise /w.js collée directement. Les instructions d’installation actuelles expliquent cette distinction. L’absence de cette seule balise ne prouve pas une défaillance du connecteur.
Utilisez une seule question publique contrôlée pour vérifier l’étape de réponse. Il s’agit ici de savoir si le parcours de requête fonctionne, pas d’établir un nouveau benchmark de qualité des réponses. Excluez les données sensibles de compte des entrées de test et des dossiers de diagnostic.
Lire l’erreur de politique du navigateur avant de modifier une directive
Content Security Policy est une politique du navigateur concernant les ressources. Le guide CSP de MDN explique comment elle limite le contenu qu’une page peut charger ou exécuter. Un widget peut dépendre d’autres ressources que son script initial : un chargeur réussi peut donc être suivi d’une requête de configuration ou de styles bloqués.
La documentation de script-src concerne les sources de scripts et leur exécution. La documentation de connect-src concerne les connexions faites par des interfaces telles que fetch. Styles et cadres ont leurs propres contraintes. Rapprochez le message réel du navigateur de la ressource et de la directive qu’il nomme.
Créez un petit relevé de ressource : URL demandée, fournisseur attendu, type de ressource, directive nommée, résultat observé et responsable de la politique. Vérifiez les exigences actuellement documentées du fournisseur. Ne déduisez pas ces origines de l’exemple d’un autre prestataire et n’approuvez pas un joker étendu pour faire disparaître l’avertissement.
La page Intercom de dépannage CSP décrit les ressources et le diagnostic propres à Intercom. Les conseils tawk.to sur les images absentes du widget décrivent ses symptômes de ressources. Ces pages montrent pourquoi une interface partiellement visible peut rencontrer un problème propre à une ressource ; ce ne sont pas des recettes de configuration d’Achla.
Si le responsable sécurité utilise une politique en mode rapport seul pour observer, distinguez-la de la politique appliquée. MDN distingue signalement et application. Une observation en mode rapport seul ne prouve pas que la politique appliquée autorise le widget, et l’ajouter n’autorise pas à retirer les protections existantes.
Traiter le consentement comme une séquence d’états
Un chargement retardé peut être intentionnel. Avant de qualifier un script absent de défaut, établissez le comportement de chargement approuvé du site et identifiez le responsable de sa configuration de consentement.
La documentation ChatLab du chargement après consentement décrit une approche explicite pour ChatLab. Elle ne démontre ni une intégration automatique avec tout gestionnaire de consentement, ni une séquence identique chez un autre fournisseur. Le responsable du site doit déterminer la classification et les exigences applicables.
Utilisez un relevé distinct pour chaque état prévu :
| État du visiteur | Ce qu’il faut observer | Hypothèse à éviter |
|---|---|---|
| Nouveau visiteur | Le chargeur est-il demandé avant un choix ? | Tout chatbot doit se charger immédiatement |
| Refus | Le comportement de refus approuvé est-il maintenu ? | L’absence du widget est automatiquement un défaut |
| Accord | La séquence attendue commence-t-elle et s’achève-t-elle ? | Un script réussi prouve toute l’interaction |
| Retour | Les choix mémorisés produisent-ils le comportement voulu ? | La session de l’éditeur représente tous les visiteurs |
Ce sont des pistes d’observation, pas des conclusions juridiques ni des résultats de tests revendiqués. Si le comportement attendu diffère du comportement observé, notez l’état et fournissez au responsable consentement un problème reproductible. Ne contournez pas le mécanisme de consentement comme raccourci générique de dépannage.
Un outil de consentement peut piloter le chargement du script tandis qu’une politique du navigateur pilote une requête ultérieure. Consignez les deux au lieu de choisir prématurément une explication. Un état peut révéler plusieurs problèmes indépendants.
Et si une politique de styles stricte est incompatible avec le widget ?
Parfois, la bonne conclusion est que les exigences documentées d’un widget ne correspondent pas à la politique du site.
Le guide d’installation actuel d’Achla précise que le widget injecte sa feuille de styles dans un élément style et mentionne l’autorisation des styles intégrés parmi ses exigences CSP. C’est un fait de compatibilité à examiner avec le responsable sécurité, pas une recommandation d’exception générale unsafe-inline. La documentation examinée ne démontre pas d’API Achla d’intégration par nonce ou hachage.
Un autre fournisseur peut documenter un autre mécanisme. Le journal des modifications CSP de SiteSpeakAI décrit la prise en charge des nonces pour son propre widget. Cette déclaration n’établit pas une prise en charge équivalente dans Achla et ne justifie pas la copie de l’attribut dans un autre script.
Si le site impose une politique stricte de nonces ou de hachages, suspendez l’intégration jusqu’à vérification d’un comportement compatible. Demandez des preuves actuelles au fournisseur ou évaluez une alternative dont les exigences documentées respectent la politique. Associez son responsable : un bouton visuellement fonctionnel ne vaut pas acceptation d’une frontière de sécurité modifiée.
Les conseils BoldDesk de dépannage CSP abordent également les exigences de son propre chat en direct. Utilisez chaque documentation pour cadrer les questions, pas pour agréger les exceptions de plusieurs fournisseurs en une politique permissive.
Préparer un dossier de diagnostic expurgé
Une transmission utile permet au mainteneur du site, au responsable consentement ou au fournisseur de reproduire le problème sans recevoir d’informations privées.
Incluez la page publique, la date d’observation, le mécanisme d’intégration, l’emplacement prévu, l’état de consentement du visiteur et l’étape en échec dans la matrice. Ajoutez l’origine de la ressource concernée, le résultat de la requête et le message de console. Précisez si l’interface était absente, masquée, configurée mais incapable de répondre, ou en attente d’un choix de consentement prévu.
Un relevé hypothétique pourrait par exemple dire : « Page de politique publiée ; nouvelle session anonyme ; accord choisi ; chargeur demandé ; requête de configuration bloquée par la directive de connexion nommée ; aucune requête de réponse à ce stade. » Il délimite l’enquête sans affirmer qu’un client réel a vécu cette séquence.
Masquez identifiants, clés privées, identifiants de session, messages personnels et données de compte. Le dossier ne doit pas contenir de conversation privée complète ni d’archive réseau non examinée. Consignez le minimum nécessaire pour distinguer la ressource et l’état en échec, avec un responsable nommé pour la décision suivante.
Retester le même état après une correction approuvée
Définissez la correction et son responsable avant application. Répétez ensuite la même page, le même état visiteur et la même question publique. Notez ce qui a changé et quelle étape réussit désormais ou reste inconnue. Évitez de regrouper remplacement du script, modification du consentement et de la politique en un résultat inexpliqué.
Si la console signale encore une violation, transmettez au responsable sécurité la directive et l’origine exactes. Si la réponse de configuration n’est pas prête, suivez les prérequis documentés du fournisseur. Si seule l’interface est masquée, examinez son emplacement dans la page plutôt que les permissions réseau.
Un retest réussi du chargement établit uniquement le comportement observé. Il ne certifie ni accessibilité, ni conformité de confidentialité, ni exactitude des réponses, ni compatibilité avec tous les navigateurs et toutes les pages. Les échecs ambigus doivent rester ouverts avec une demande de preuves, plutôt qu’être traités par un contournement non vérifié d’un autre fournisseur.
Évaluer les exigences actuelles d’Achla avant la connexion
Utilisez la matrice remplie comme liste de compatibilité : l’installation documentée du widget, ses exigences de politique et de contenu public correspondent-elles à ce site précis ? Pour les parcours propres à un CMS, examinez le connecteur WordPress existant ou le module Drupal. Un script générique dépend de la capacité réelle du site à l’inclure et à l’autoriser ; il ne démontre pas une intégration dédiée avec un autre CMS.
Une fois l’interface et le parcours de requête compris, utilisez séparément le guide du chatbot fondé sur le contenu du site pour les sources et la fiche d’évaluation des réponses étayées pour leur justification. Si le périmètre documenté convient, commencez le parcours d’intégration existant. Maintenez la suspension d’une incompatibilité avec une politique stricte jusqu’à résolution par des preuves. Le résultat utile est une décision vérifiable concernant votre site, dont les protections conservent leurs responsables et restent intactes.
