Intégrer le chatbot SAWL sur un site WordPress d'office de tourisme

WordPress équipe une large part des sites d'offices de tourisme, des petits OT communaux aux agences d'attractivité. SAWL s'intègre sur un site WordPress sans plugin dédié, sans modification du thème et sans intervention développeur lourde. Cette page décrit les trois méthodes d'intégration courantes, les précautions, et ce que voit votre équipe de contenu au quotidien.

Pourquoi WordPress et pourquoi un widget HTML plutôt qu'un plugin dédié

WordPress reste le CMS dominant chez les offices de tourisme francophones, pour des raisons connues : coût d'entrée faible, large écosystème de thèmes et de plugins, communauté francophone active, compétences disponibles chez la plupart des agences web locales. Beaucoup d'OT communaux ou intercommunaux pilotent leur site avec un thème WordPress personnalisé ou un page builder (Elementor, Divi, Beaver Builder), maintenu en interne ou par un prestataire ponctuel.

SAWL ne fournit pas de plugin WordPress dédié, et c'est un choix assumé. Le widget est livré sous forme d'une balise HTML universelle de deux lignes, qui fonctionne à l'identique sur WordPress, Drupal, Typo3, Joomla, SPIP, Sanity, Webflow ou tout autre CMS acceptant du code personnalisé. Cette stratégie présente trois avantages pour une collectivité : pas de dépendance à un plugin tiers à maintenir, pas de risque de conflit avec vos autres plugins, pas de mise à jour de plugin à suivre en plus du reste. Le code du widget est chargé depuis nos serveurs et se met à jour côté SAWL sans rien changer sur votre site.

Méthode 1 : plugin d'insertion de code dans le header ou le footer

La méthode la plus utilisée consiste à passer par un plugin d'insertion de code comme Insert Headers and Footers, WPCode ou équivalent. Ces plugins, installés en quelques clics depuis l'annuaire WordPress, permettent d'ajouter du code HTML dans le header ou juste avant la balise de fermeture du body, sur toutes les pages du site, sans toucher au thème.

Côté gouvernance, cette méthode a l'avantage de ne demander aucune compétence développeur : un administrateur WordPress peut poser le widget seul, le tester sur une page, le retirer si besoin. Elle est bien adaptée aux offices de tourisme qui pilotent leur site en interne, sans prestataire technique dédié. Elle convient aussi aux sites dont le thème est régulièrement mis à jour par un prestataire externe, puisque le widget est découplé du thème et survit aux mises à jour.

Le seul point d'attention est la charge : l'ajout du widget représente environ 80 Ko de JavaScript chargé en asynchrone après le contenu principal, sans bloquer l'affichage de la page. Sur un site déjà chargé de scripts tiers (analytics, trackers, plugins de réservation), nous recommandons de vérifier le score Core Web Vitals après intégration, ce qui se fait en quelques minutes via PageSpeed Insights.

Méthode 2 : bloc HTML personnalisé dans Gutenberg

Si votre office de tourisme utilise l'éditeur Gutenberg (l'éditeur natif de WordPress depuis la version 5), vous pouvez insérer le widget SAWL page par page via un bloc HTML personnalisé. Cette méthode est utile pour tester le widget sur une seule page avant un déploiement global, ou pour le positionner uniquement sur certaines pages stratégiques (par exemple la page d'accueil et les pages rubriques, mais pas la page légale).

Côté équipe, cela donne de la souplesse : votre responsable communication peut poser ou retirer le widget sans passer par un administrateur. L'inconvénient est que la maintenance devient page par page, ce qui convient mal à un site de trente pages mais très bien à un test d'une ou deux pages. En pratique, nous voyons des offices de tourisme l'utiliser pour une phase pilote d'une semaine avant de basculer sur la méthode 1 (plugin d'insertion) pour le déploiement généralisé.

Méthode 3 : snippet dans le thème enfant

Pour un site WordPress maintenu par une agence ou un développeur interne, la méthode la plus propre reste d'ajouter le widget directement dans le thème enfant, dans le fichier footer.php ou via une fonction hook dans functions.php. Cette méthode garantit que le widget est servi sur toutes les pages, résiste aux mises à jour du thème parent, et reste sous contrôle de version si le thème est versionné dans un dépôt.

Elle demande en revanche une intervention développeur, ce qui peut être une friction pour les OT sans prestataire technique régulier. Pour ceux qui ont un contrat de tierce maintenance applicative (TMA) sur leur site WordPress, c'est typiquement une demande de quinze à trente minutes de développement, facturable à la tâche. Nous fournissons les deux lignes HTML exactes à intégrer, ainsi que des consignes de positionnement (avant </body>, en asynchrone).

Compatibilité avec les principaux thèmes et page builders WordPress

Le widget SAWL est indépendant du thème WordPress utilisé. Il fonctionne avec les thèmes par défaut (Twenty Twenty-Four et versions précédentes), les thèmes commerciaux populaires (Astra, GeneratePress, Kadence, OceanWP), les thèmes spécialisés tourisme et collectivité, ainsi qu'avec les sites assemblés via page builder (Elementor, Divi, Beaver Builder, Bricks). Dans Elementor, l'intégration passe par un widget HTML. Dans Divi, par un module Code. Dans Bricks, par un élément HTML brut. La logique est la même partout : le widget est une balise HTML, le page builder l'accepte sans traitement particulier.

La seule incompatibilité connue concerne les sites qui filtrent agressivement le code HTML en sortie via un plugin de sécurité mal configuré (par exemple, un plugin qui supprime toutes les balises <script> non whitelistées). Ce cas est rare et se détecte immédiatement : si le widget n'apparaît pas après intégration, c'est la première piste à vérifier. Nos équipes peuvent accompagner ce diagnostic lors de la mise en route.

Ce que voit votre équipe éditoriale au quotidien

Une fois le widget intégré, votre équipe éditoriale n'a rien à faire dans WordPress. Le chatbot s'affiche côté visiteur, les réponses viennent de votre périmètre Apidae et de vos sources complémentaires, les indicateurs (top questions, intentions, langues) sont consultables dans votre espace client SAWL, sans interaction avec l'administration WordPress.

Si votre équipe veut modifier l'emplacement du widget, changer les couleurs, activer ou désactiver temporairement le chatbot sur certaines plages, cela se fait dans l'espace client SAWL, pas dans WordPress. Cette séparation est volontaire : votre CMS gère vos contenus, SAWL gère le chatbot, et les deux coexistent sans se gêner. Pour un directeur d'office de tourisme, cela veut dire que la gouvernance technique du site WordPress reste exactement comme avant, sans ajout de responsabilité pour l'équipe web.

Rédigé par l'équipe Digitz, intégrateurs Apidae depuis 2014. Plus de 25 plateformes Apidae déployées pour les collectivités. Dernière mise à jour : 11 avril 2026.