Si un widget de chatbot WordPress recouvre un bouton sur mobile, choisissez son emplacement en fonction de la tâche principale de la page et de la personne qui contrôle le modèle publié. Un bouton flottant adapté à un article peut gêner un formulaire de contact. Un encadré intégré peut convenir à une page d’aide sans apparaître ailleurs. Consignez ces différences avant de modifier le widget à l’échelle du site.
Ce guide propose un registre des responsabilités par page, un tableau de choix d’emplacement et une fiche de validation. Ils aident un propriétaire de site ou une agence à décider où placer le chat sans prendre l’aperçu de l’éditeur pour une preuve. Les exemples sont des scénarios proposés, pas des tests clients ni des résultats mesurés.
Auteur : Achla AI, organisation. Révision : 14 octobre 2026. Préparé avec l’aide de l’IA à partir de la documentation officielle et des sources produit examinées. Cette date de révision n’est pas une date de publication.
Partir de la tâche sur mobile, pas du coin réservé au chat
Rédigez une phrase pour chaque famille de pages : « Le visiteur doit lire cette politique », « envoyer cette demande » ou « trouver le prochain article pertinent ». Identifiez ensuite les commandes nécessaires pour terminer cette tâche. Un chatbot doit aider à trouver de l’information sans compliquer l’action déjà prévue sur la page.
Évitez de choisir d’abord un coin universel, puis de négocier chaque conflit après coup. La position d’un bouton d’appel, d’une commande de consentement ou d’une navigation fixe fait partie de la décision. L’emplacement du chat est un choix de mise en page partagé : associez donc la personne responsable de ces éléments.
Ce besoin est concret : une question sur le forum WordPress décrit une icône de chat qui recouvre un bouton de publication sur mobile. Ce témoignage historique concerne une autre extension ; il ne démontre pas un défaut d’Achla ou de votre site.
Qui contrôle le balisage de chaque page WordPress ?
Distinguez trois éléments : l’endroit où une personne modifie le contenu, le modèle qui génère la page publique et l’intégration qui charge le widget. Leurs responsables peuvent être différents. Un rédacteur peut déplacer un bloc alors qu’une agence contrôle le pied de page et qu’une extension fournit le bouton de chat.
Pour le contenu Gutenberg, WordPress propose un bloc Code court qui insère le rendu d’un shortcode. Sa présence indique un emplacement dans l’éditeur, pas le comportement final de chaque intégration. Notez la page qui le contient et vérifiez le balisage public obtenu.
Pour les pages Elementor, le widget HTML documenté accepte du HTML, des scripts et des shortcodes. Cette possibilité ne certifie pas un chatbot particulier dans tous les modèles, fenêtres contextuelles ou thèmes Elementor. Considérez le constructeur comme un élément de la configuration réelle à examiner.
La documentation HTML personnalisé de WordPress explique aussi le filtrage du balisage interdit selon les permissions. Si du code figure dans l’éditeur mais disparaît après l’enregistrement, examinez le processus d’édition autorisé. N’accordez pas de permissions plus larges uniquement pour imposer un widget sur une page.
Utilisez ce registre des responsabilités avant de choisir l’emplacement :
| Famille de pages | Tâche principale du visiteur | Modèle ou mise en page publique | Responsable éditorial | Responsable du rendu du widget | Responsable de la commande partagée |
|---|---|---|---|---|---|
| Pages de services | Comprendre le service | Noter le modèle réel | Nommer le rédacteur | Nommer le mainteneur | Nommer le responsable du CTA |
| Articles | Lire et trouver des informations connexes | Noter le modèle d’article | Nommer le rédacteur | Nommer le mainteneur | Nommer le responsable de la navigation |
| Page de contact | Envoyer la demande existante | Noter la mise en page du formulaire | Nommer le rédacteur | Nommer le mainteneur | Nommer le responsable du formulaire |
Laissez les responsabilités inconnues apparentes. « Quelqu’un gère Elementor » ne suffit pas pour attribuer une correction qui touche le pied de page partagé du site.
Choisir l’emplacement selon la tâche et la famille de pages
Le tableau suivant fournit des propositions de départ, pas des réglages par défaut déjà testés. Choisissez un emplacement que vous pouvez réellement maintenir dans le respect des règles documentées de l’intégration.
| Famille de pages | Emplacement envisagé | Question de décision | Preuve nécessaire |
|---|---|---|---|
| Page de présentation ou de service | Bouton flottant | Les visiteurs peuvent-ils toujours atteindre le CTA de la page ? | Page publique avec ses commandes fixes visibles |
| Article long | Bouton flottant ou section intégrée choisie délibérément | L’aide est-elle repérable sans masquer les commandes de lecture ? | Modèle d’article réel et états de défilement |
| Page de politique ou d’aide | Intégration dans une section dont le responsable est clairement identifié | L’encadré interrompt-il des conditions essentielles ? | Ordre du contenu publié et liens vers les sources |
| Page de contact ou de formulaire | Parcours de contact existant ; évaluer le chat séparément | Peut-on terminer la tâche du formulaire quand le chat est ouvert et fermé ? | Commandes, validation du formulaire et états du clavier virtuel |
Le connecteur WordPress officiel d’Achla utilise un seul mode d’emplacement pour tout le site. En mode Inline, il se charge sur les pages qui contiennent son shortcode ou son bloc ; les autres pages n’affichent aucun widget. En mode Bubble ou Attach, le shortcode ou le bloc n’ajoute pas d’encadré intégré supplémentaire. Pour obtenir un bouton flottant partout et une intégration dans une page précise, il faut suivre l’approche manuelle documentée séparément. Consultez le contrat d’installation actuel.
Cette contrainte compte davantage qu’une préférence visuelle. Un tableau proposant différents emplacements ne peut pas faire changer le connecteur de mode selon la page. Si vos exigences sont incompatibles, revoyez la couverture envisagée ou demandez au mainteneur responsable d’évaluer une intégration adaptée. Le guide extension ou script intégré traite de ce choix d’installation plus général.
Constituer le registre des emplacements et des obstructions
Créez une ligne par famille de pages significative, puis ajoutez les exceptions individuelles. Réutilisez le tableau des responsabilités plutôt que de tenir une deuxième liste de noms. Le registre doit relier un problème visible à une page, à un état précis et à une personne responsable.
| Champ | Informations à consigner |
|---|---|
| Page et tâche | URL publique exacte et action que le visiteur doit terminer |
| Périmètre d’édition et de rendu | Éditeur, modèle public réel, mode du widget et responsable |
| Commandes voisines | Navigation fixe, CTA local, commande de consentement et actions du formulaire |
| État du visiteur | Première visite ou retour ; consentement pertinent ; chat ouvert ou fermé |
| État de saisie | Clavier virtuel visible ou masqué, si pertinent |
| Preuve | Capture d’écran ou courte procédure de reproduction ; navigateur et appareil ; date de révision |
| Constat | Commande précisément masquée ou rendu attendu absent ; « non vérifié » si inconnu |
| Correction proposée | Modification minimale et ciblée, responsable et famille de pages concernée |
| Nouveau test et décision | Même tâche et même état après correction ; accepter, réviser ou suspendre |
Utilisez le registre dans cet ordre :
- Choisissez une page publique représentative et identifiez le véritable responsable de son modèle.
- Notez l’emplacement prévu et les commandes concurrentes de la page.
- Documentez l’état précis du visiteur et toute obstruction observée.
- Attribuez la plus petite correction possible et répétez la même tâche avant de décider.
Choisissez des intitulés de preuve qu’un autre mainteneur pourra reconnaître. « Page de contact, chat ouvert, clavier visible, bouton d’envoi inaccessible » est plus utile que « mauvais affichage mobile ». Une capture seule peut montrer le chevauchement sans révéler la séquence qui le provoque : conservez donc les deux.
Consignez les absences aussi soigneusement que les obstructions. En mode Inline d’Achla, une page sans le shortcode ou le bloc intégré n’a volontairement pas de widget. C’est un choix de couverture à examiner, pas la preuve qu’une fenêtre devrait s’afficher partout. Précisez si cette absence est voulue avant d’ouvrir un ticket d’assistance.
Examiner la page publiée avec ses véritables commandes concurrentes
Utilisez l’interface publique effectivement reçue par les visiteurs. Vérifiez quel conteneur ou chargeur attendu est réellement présent, puis confirmez où le widget s’affiche. Comparez ce résultat au registre des responsabilités ; la zone de travail d’un éditeur ne permet pas de déterminer quel modèle partagé ou quelle intégration a généré la page finale.
Examinez la page avec ses propres commandes visibles. La documentation des boutons flottants d’Elementor décrit les réglages d’emplacement de ses éléments flottants. Si le site en utilise déjà un, notez son responsable et sa position à côté de l’exigence du chat. Ne supposez pas que deux composants flottants positionnés indépendamment se coordonneront automatiquement.
Observez les changements d’état : une commande de consentement peut rester visible, un CTA fixe apparaître après défilement ou le clavier virtuel réduire l’espace utilisable lors de la saisie. Vérifiez l’action de la page dans chaque état pertinent. L’objectif est une observation reproductible, pas une promesse générale selon laquelle un affichage « responsive » règle les conflits entre commandes.
Les explications W3C sur le focus non masqué précisent l’exigence selon laquelle les composants ayant le focus ne doivent pas être entièrement cachés par du contenu créé par l’auteur de la page. Considérez ce point séparément au titre de l’accessibilité. Ce registre d’emplacement ne démontre pas une conformité complète aux WCAG.
Vérifiez aussi qui fournit le chargeur. Achla documente l’utilisation du connecteur officiel ou d’une balise manuelle, jamais des deux. Son connecteur utilise son propre chargeur plutôt qu’une balise manuelle littérale /w.js. Une recherche limitée à ce nom de fichier ne peut donc pas prouver un échec de l’extension. Suivez les vérifications de dépannage documentées avant d’ajouter une autre installation.
Exemples détaillés : même widget, responsables de pages différents
Ces exemples hypothétiques illustrent des décisions à examiner ; aucun ne rapporte un test de navigateur achevé.
Un modèle d’article et une page de contact partagent un pied de page. Le responsable des articles propose un bouton flottant. Celui de la page de contact identifie une commande fixe de demande de renseignements dans la même zone. Consignez les deux familles de pages avant de modifier l’emplacement global. L’étape suivante proposée consiste à vérifier que l’emplacement partagé préserve les deux tâches, pas à considérer l’aperçu d’article comme un résultat valable pour tout le site.
Une page d’aide Gutenberg contient un shortcode intégré. Le responsable du contenu place l’encadré sous l’introduction. Le mainteneur propose le mode Inline d’Achla et note que les pages de services ordinaires n’ont pas de shortcode. Le registre indique explicitement qu’elles n’auront aucun widget dans ce mode du connecteur. Le propriétaire peut accepter cette couverture ou la revoir avant la configuration.
Une page Elementor semble correcte dans l’éditeur. La page publique peut utiliser un modèle partagé contrôlé par une autre personne. Commencez par identifier le modèle publié et le rendu réel. Si le conteneur requis est absent au montage du widget, changer les couleurs ou déplacer l’espace réservé dans l’éditeur ne prouve pas que l’exigence est satisfaite. Attribuez la question du rendu public au responsable du modèle.
Ces exemples distinguent trois décisions : où l’interface est modifiée, où elle apparaît et si les visiteurs peuvent terminer la tâche de la page.
Accepter, réviser ou suspendre avec un responsable désigné
N’acceptez un emplacement que pour les pages et les états étayés par des preuves consignées. Une ligne d’article validée ne clôt pas une ligne de contact non vérifiée. Gardez une exigence globale ouverte jusqu’à l’examen des familles de pages concernées.
Révisez lorsqu’une commande identifiée est masquée, qu’un emplacement intégré apparaît dans le mauvais contexte ou que la couverture prévue diffère du rendu du connecteur. Attribuez la correction au responsable de ce périmètre. Une modification de modèle partagé nécessite de revérifier les lignes affectées, pas seulement la page utilisée pour montrer la correction.
Suspendez si l’action principale du visiteur est impossible ou si les responsabilités sont floues. Conservez le parcours habituel de contact ou de navigation tant que la décision reste ouverte. Pour les vérifications pratiques au clavier, au lecteur d’écran et selon la fenêtre d’affichage, consultez le guide d’accessibilité de la barre de recherche. La décision traitée ici reste la responsabilité de l’emplacement et l’obstruction des pages.
Évaluer le connecteur WordPress documenté à partir de votre registre
Comparez le connecteur WordPress à vos exigences réelles de couverture et d’emplacement. Le rôle documenté d’Achla est de répondre à partir du contenu public du site en fournissant des sources. Ne lui attribuez pas un chat humain assuré par une équipe, des réservations ou une automatisation des formulaires qui auraient été vérifiés.
Comparez les modes documentés à votre registre, consultez les offres actuelles et utilisez le parcours de démarrage si ce rôle délimité convient. Si vous choisissez encore le type d’expérience de recherche, la présentation de la recherche IA sur site fournit un contexte plus large. Gardez les conditions d’emplacement consignées à disposition du responsable qui approuvera tout lancement effectif.