Intégrer SAWL sur Typo3, Joomla, SPIP, Sanity, Webflow et autres CMS du secteur tourisme

Tous les offices de tourisme et collectivités n'utilisent pas WordPress ou Drupal. Beaucoup pilotent leur site avec Typo3, Joomla, SPIP, Sanity, Webflow, ou avec des plateformes tourisme spécialisées (Ingénie, Raccourci, plateformes Apidae-native). Le widget SAWL est une balise HTML universelle, ce qui veut dire qu'il s'intègre à l'identique partout. Cette page détaille les spécificités d'intégration sur les principaux CMS restants.

Principe commun : une balise HTML, pas un plugin par CMS

Le widget SAWL est livré sous la forme d'une balise HTML universelle de deux lignes (environ 80 Ko chargés en asynchrone). Ce choix d'architecture élimine la question du plugin par CMS : il n'y a pas de plugin Typo3, pas de module Joomla, pas de plugin SPIP, pas d'extension Webflow à installer. La balise est acceptée telle quelle par tout CMS qui permet d'insérer du code HTML personnalisé dans un template, un gabarit ou une zone libre.

Cette approche a trois avantages pour les collectivités utilisant des CMS moins répandus dans l'écosystème chatbot. D'abord, pas de dépendance à une extension tierce qui pourrait ne plus être maintenue. Ensuite, pas de limitation par version du CMS : le widget fonctionne sur Typo3 10, 11 et 12, sur Joomla 3 et 4, sur SPIP 3 et 4, avec la même balise. Enfin, les équipes techniques de la collectivité retrouvent une logique qu'elles connaissent déjà, puisqu'elles ont certainement déjà intégré des scripts tiers de ce type (analytics, cartes, vidéos embedées).

Typo3 : intégration via Fluid template ou TypoScript

Typo3 est présent dans plusieurs offices de tourisme et directions de la culture, notamment pour des collectivités ayant historiquement fait un choix de CMS open source plus européen que WordPress. L'intégration de SAWL sur Typo3 passe par deux voies principales. La première est d'ajouter la balise dans le template Fluid du thème actif, typiquement dans le fichier Layouts/Default.html ou dans un partial de footer. La seconde est d'utiliser TypoScript pour injecter la balise dans la zone de footer du site, ce qui donne un contrôle plus fin mais demande une compétence Typo3 confirmée.

Pour une intégration sans compétence Typo3 avancée, il est possible de poser la balise via l'élément de contenu HTML pur dans la page de pied (footer), à condition que le filtre RTE de votre installation autorise les balises script. Si ce filtre bloque, c'est une option de configuration que votre administrateur Typo3 peut ajuster dans le backend.

Joomla : module HTML personnalisé dans la position footer

Joomla reste utilisé sur une partie des sites d'offices de tourisme plus anciens ou sur des structures qui ont fait historiquement ce choix de CMS. L'intégration SAWL sur Joomla passe par un module de type HTML personnalisé, créé dans le gestionnaire de modules de l'administration, publié sur la position footer ou debug du template actif. La balise SAWL est collée dans le champ HTML du module, le module est publié sur toutes les pages, et le widget s'affiche sur le site.

Un point d'attention sur Joomla : le filtre de texte par défaut de Joomla peut supprimer les balises script si le profil du rédacteur n'a pas les droits nécessaires. La solution consiste à créer le module en étant connecté en tant qu'administrateur, ou à ajuster les permissions de filtrage pour les groupes qui gèrent les modules HTML. Ce réglage est documenté dans la documentation Joomla officielle et se modifie en quelques clics.

SPIP : intégration par modèle ou squelette

SPIP est le CMS historique de nombreux sites institutionnels français, incluant des sites d'office de tourisme et de collectivité. Sa logique de squelettes (templates) diffère des autres CMS : l'intégration de SAWL se fait directement dans le fichier de squelette, typiquement inc/pied.html ou un fichier équivalent selon votre thème SPIP, où l'on insère la balise HTML juste avant la fin du document.

Si votre site SPIP utilise un modèle d'habillage spécifique (par exemple un modèle Spipr ou un squelette personnalisé livré par votre agence), l'intégration suit la logique de ce modèle. Pour une première mise en route, nous recommandons de passer par votre intégrateur SPIP, qui pose la balise dans le squelette et valide le rendu en quelques minutes. SPIP étant un CMS moins répandu que WordPress, la compétence est plus concentrée chez des agences spécialisées, mais l'intégration technique elle-même reste triviale (deux lignes dans un squelette).

Sanity et frontends découplés (Next.js, Nuxt, Gatsby)

Sanity n'est pas à proprement parler un CMS au sens WordPress : c'est une plateforme de gestion de contenu headless dont le frontend est réalisé séparément (typiquement en Next.js, Nuxt ou Gatsby). Dans ce cas, l'intégration de SAWL ne se fait pas dans Sanity lui-même mais dans le frontend qui le consomme. La balise HTML du widget est ajoutée dans le layout du frontend, par exemple dans le composant _app.tsx (Next.js) ou app.vue (Nuxt), de façon à être servie sur toutes les pages.

Cette architecture est de plus en plus courante sur les sites tourisme récents, notamment pour les sites réalisés par des studios qui construisent des frontends modernes et performants. L'intégration SAWL y est particulièrement simple, puisque ces frameworks acceptent nativement l'ajout de balises HTML ou de scripts via des composants standards (next/script pour Next.js, par exemple).

Webflow, Ingénie, Raccourci et plateformes Apidae-native

Webflow permet d'ajouter du code personnalisé via le panneau Custom Code des paramètres du site, en posant la balise SAWL dans la section Before </body> tag. Le widget est alors servi sur toutes les pages du site Webflow, sans impact sur le design ni sur le CMS natif.

Les plateformes tourisme spécialisées (Ingénie, Raccourci, et les plateformes Apidae-native comme celles proposées par Digitz, Apidae Lab, ou d'autres intégrateurs Apidae) disposent généralement d'une zone HTML libre dans leur interface d'administration, prévue justement pour intégrer des scripts tiers (analytics, chat, widgets externes). La balise SAWL s'y insère comme n'importe quel autre tag, et le rendu est immédiat. Pour ces plateformes, nous travaillons directement avec l'équipe d'intégration de la plateforme concernée lorsque la collectivité le demande, pour cadrer la zone précise d'insertion et valider le rendu.

Dans tous les cas, le point commun est le même : SAWL ne demande aucune adaptation au CMS. La collectivité conserve son choix technique, sans avoir à migrer ou à ajouter une dépendance logicielle.

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.