Comment développer un site internet touristique performant

1. Comment développer un site internet touristique performant ?

1.1. L’organisation des institutionnels du tourisme

Les organisations institutionnelles du tourisme, qu’il s’agisse des Offices de Tourisme, des points d’information touristiques, des CDT (Comités départementaux du Tourisme) ou ADT (Agences de développement Touristique, elles aussi, départementales), des CRT (Comités Régionaux du Tourisme), et aujourd’hui, avec l’apparition des Offices de Tourisme Intercommunaux, issus du regroupement de différents offices à l’échelle d’une intercommunalité (Communauté d’Agglomération, ou Métropole), sont chargées d’une mission d’accueil et conseils aux touristes et visiteurs.

1.2. Les missions

Cette mission est évidemment, entre autre, rendue au travers de différents supports numériques, au premier rang desquels, le site internet ainsi que toutes ses déclinaisons que peuvent être les sites internet mobile en responsive design, les applications mobiles, les réseaux sociaux, les écrans d’affichage dynamique, ou les bornes interactives.

Au delà de la mission d’information exhaustive, au titre de la délégation de service public dont ces établissements sont en charge, se greffe souvent une approche commerciale de promotion des prestataires adhérents, au travers d’offres de communication promotionnelle packagée, et de mesure des audiences et publics touchés.

1.3. Les outils

A l’aube de la numérisation et de la dématérialisation des outils professionnels, de nombreuses bases de données ont émergé dans les départements et régions françaises, fruits d’initiatives souvent isolées, certes motivées, mais manquant évidemment d’uniformisation, de normalisation, et de coopération. C’est ainsi que l’on a pu voir fleurir différents Systèmes d’Information Touristique (SIT), tels que Patio dans les Bouches du Rhône, ACVS dans le Var et les Alpes de Haute-Provence, Tourinsoft, et d’autres dont les noms nous échappent aujourd’hui.

L’un de ces acteurs, nommé alors SITRA (Système d’Information Touristique de Rhône-Alpes) a su peu à peu étendre sa notoriété et son influence, au-delà de région qui l’a vu naître. C’est la raison pour laquelle il a dû se libérer de l’ancrage local gravé en son nom, et devenir APIDAE.

APIDAE offre aux institutionnels du tourisme une plateforme complète de saisie, qualification et mise à disposition de l’offre touristique des territoires adhérents. Il dispose aujourd’hui d’un quasi monopole en France.

1.4. La diffusion

APIDAE met à disposition des développeurs et intégrateurs une API complète, permettant aux prestataires en développement web et agences digitales, de mettre en oeuvre des annuaires touristiques efficaces, notamment au travers d’un référentiel de métadonnées descriptives et qualifiantes, à partir desquelles il devient possible de réaliser des filtres de recherche dynamiques, précis, des représentations cartographiques, ou encore, des recherches par date, par zone ou par typologie.

2. SynApi En bref

2.1. Pourquoi SynApi

L’information délivrée par APIDAE au travers de ses API est certes complètes, mais elle est, disons, professionnelle. Qualité ou inconvénient ? Les deux aspects à la fois, évidemment, car cette information est :

Précise d’un point de vue des professionnels du tourisme, et donc technique. C’est pourquoi elle doit être retravaillée, afin de traduire ce langage technique dans des termes plus parlants pour le public, et permettre d’ajouter la touche de séduction nécessaire à la conversion attendue (c’est du marketing ? oui oui !)
Techniquement, volatile. Elle est fiable, certes, disponible en temps réel, la plupart du temps. Mais un système robuste se doit, selon les 10 commandements de l’ingénierie logicielle, de la considérer comme possiblement indisponible. C’est donc le rôle des développeurs de mettre en oeuvre un système qui découple APIDAE des sites internet et autres supports numériques qui vont rendre cette information disponible au public.

C’est la raison pour laquelle, à Synexie, nous avons développé SynApi. Chez nous, ce n’est pas nouveau. Avant cela, SynApi s’appelait ODMS, et dialoguait déjà avec les ancêtre d’APIDAE qu’ont pu être ACVS ou Patio.

Mais aujourd’hui, c’est évidemment sur APIDAE que l’effort doit être concentré, et c’est ce que nous avons fait avec le service SynApi.

Couplé à des outils fiables, robustes et réputés, tels que Algolia, pour la recherche textuelle, ou WordPress, pour la mise en œuvre d’un site internet, SynApi propose aux professionnels du tourisme la plateforme performante et rassurante pour injecter les contenus d’APIDAE dans des sites internet, mobiles, ou bornes interactives, avec un niveau de rapidité inégalé, aussi bien dans les opérations de consultations de fiches, affichages de sélection, filtrages dynamiques des listes, cartographies interactives, et recherche textuelle (presque) aussi souple que Google !

2.2. Historique

SynApi est un ensemble de services hébergés permettant d’utiliser des informations touristiques afin de les afficher dans des sites internet, des applications mobiles ou des bornes interactives.

La source de données de SynApi peut être un Système d’Information Touristique (SIT) tel que APIDAE, utilisé par une majorité des Offices de Tourisme et Agences départementales et régionales touristiques françaises.

Le service SynApi expose en sortie une API permettant d’utiliser ces données, d’effectuer des recherches multi-critères, et de réaliser des sélections. Cette API peut être administrée au travers d’un interface web, de façon à catégoriser et enrichir les contenus exposés.

Enfin, ce service s’accompagne d’une extension WordPress, qui permet de rapidement mettre en œuvre un site internet touristique professionnel et d’y présenter des données touristiques sous forme de listes accompagnées de filtres à facettes, cartes interactives, fiches détaillées, ou encore, de recherche texte rapide, suggestive, et tolérante.

3. Le besoin

SynApi est le nom commercial donné à un ensemble de produits développés par Synexie, sous le nom de ODMS à partir de 2012, puis ODMS2 à partir de 2019.

3.1. L’héritage ODMS

Dans sa première version, ODMS s’appuyait sur différents Systèmes d’Informations Touristiques :

ACVS dans le Var et les Alpes de Haute-Provence
Patio dans les Bouches-du-Rhône,
d’autres outils confidentiels, basés sur des flux RSS voire des fichiers Excel.

3.2. ODMS2

Le développement de ODMS2 a coincidé avec l’accroissement hégémonique du réseau APIDAE au sein de tous les acteurs publics du tourisme en France.

Le besoin a été identifié auprès de nos clients, ainsi qu’au terme d’une étude technique de l’état de l’art de l’écosystème des utilisateurs et outils autour de APIDAE.

3.3. Les besoins du marché

3.3.1. A propos de la plate-forme APIDAE

Le système est un outil métier, ouvert au travers d’API complètes, mais n’a pas vocation a être utilisé directement comme backend d’un site internet ou d’une borne interactive. Il est fortement recommandé aux prestataires techniques de développer des outils de synchronisation et mise en cache des données exploitées.
Le référentiel est le point faible du système. Il est trop vaste, trop technique (orienté professionnels du tourisme) et son héritage contient une part importante de dette technique, au travers de nombreux doublons, et d’une arborescence composée de racines multiples.
Une initiative de création d’un référentiel unique, complet et cohérent, avait été réalisée par un groupement d’acteurs touristiques, appelé référentiel TIF (pour Tour In France). Ce référentiel a été partiellement intégré à APIDAE, mais cette piste a finalement été abandonnée.

3.3.2. A propos de l’exploitation des données APIDAE

La mise en œuvre d’un site internet ou d’une borne interactive ne saurait être soumise aux aléas de la disponibilité technique de la plate-forme APIDAE. Les outils de communication numérique doivent fonctionner de façon découplée, même en cas de panne de la plate-forme, ou de perte de données (contenus, médias…)
La possibilité de compléter, simplifier ou réécrire le contenu des fiches, en fonction du média cible (internet desktop, mobile, affichage dynamique, borne interactive) est impérative, et ce dans le but d’adapter les contenus aux usages, mais également dans un souci d’optimisation SEO (éviter les contenus dupliqués, optimiser les mots clés selon le contexte…)
Maximiser les performances techniques d’affichage des contenus et calculs des requêtes multicritères, au travers de mécanismes de cache des requêtes et des données.
Disposer de données à jour par rapport à leur source APIDAE, au travers d’une synchronisation rapide, fréquente, et résiliente.
Proposer une expérience de recherche efficace, rapide et moderne, en proposant des outils conformes à l’état de l’art technique actuel (recherche approchée, synonymes, tolérance aux typos, suggestions, résultats à facettes…).
Proposer une expérience utilisateur simple et intégrée pour le webmaster, au travers d’un plugin WordPress, permettant notammant l’insertion de liste et sélections au travers de shortcodes, la configuration des templates de rendu (liste, cartes, liste et carte, types de fiche détail).
Permettre d’inserér dans des pages Wordpress, du contenu statique avec des insertions de sélections, listes ou fiches.
Exploiter les différentes langues disponibles dans les fiches APIDAE et dans le référentiel, et intégrer le mécanisme d’extraction des contenus localisés en lien avec les plugins populaires de traduction et localisation de WordPress (Polylang notamment).

3.3.3. Affichage dynamique et bornes interactives

Disposer d’un socle technique unique permettant de propulser une même source de données touristiques vers les différents vecteurs de communication numérique (sites internet, applications mobiles, bornes interactives et affichages dynamiques)
Proposer sur une borne interactive une expérience utilisateur aussi riche et complète que sur un site internet (fluidité, rapidité, recherches par critères)

4. Glossaire

Ce glossaire va permettre de définir le vocabulaire utilisé par le Système d’Informations Touristiques APIDAE, ainsi que le vocabulaire issu du modèle de données de SynApi.

4.1. Glossaire APIDAE

Fiche : Document présentant une donnée touristique unitaire. Il peut s’agir :
- De données dites froides, telles qu’un hébergement, un patrimoine naturel, un monument, un commerce, un prestataire de services,
- De données dites chaudes, telles qu’un événement, une animation, une exposition…
Référentiel : Liste hiérarchisée (arborescence) de catégories et attributs descriptifs, permettant de qualifier précisément et de façon structurée toute donnée touristique. Chaque noeud est appelé élément de référence.
Critères internes : Eléments de réference complémentaires, que chaque structure juridique membre du réseau APIDAE peut créer et enrichir à sa guise afin de les attribuer à des fiches selon ses propres besoins.
Sélection : Liste de fiches résultant d’une expression booléenne réalisée avec des éléments de référence, combinée avec des ajouts canoniques de fiches. Une sélection est calculée selon son expression, chaque nuit, et la liste résultante est mise en cache.
API : Service HTTP REST permettant de récupérer, au format JSON, des fiches et des contenus de sélections.
Exports : Génération quotidiennes d’archives de documents JSON, contenant l’ensemble des fiches modifiées depuis l’export précédent, des contenus de sélections, et les éléments de référence.
Médias : Fichiers joints à une fiche. Ils peuvente être de type image, document PDF, tracé GPS, ou URL de vidéo.

4.2. Glossaire SynApi

Information Object (objet d’information) : Objet permettant de stocker le contenu d’une fiche issue d’APIDAE. La source JSON de la fiche est stockée telle quelle, et diverses informations permettant des filtrages rapides sont extraites et stockées dans des champs séparés (catégorie, localisation, identifiant, url des médias, jours d’ouverture).
Thesaurus Item (élément de thésaurus) : Liste hiérarchisée (arborescence) des différentes sources d’élément de référence du Référentiel APIDAE. Outre le référenciel APIDAE à proprement parler, le Thésaurus SynApi y ajoute :
- Les éléments de référence définis par les utilisateurs APIDAE (qui servent à enrichir la liste commune avec des éléments propres à la structure juridique qui explotite les données)
- Les communes et territoires de la zone concernée,
- Les grandes catégories de fiches
Search Criteria (critères de recherche) : Un critère de recherche est défini de façon similaire à une sélection APIDAE, par le biais d’une expression booléenne impliquant des éléments de thésaurus. Cette expression peut être complétée par l’ajout de fiches unitaires, l’exclusion de fiches unitaires, ou l’ajout de critères géographiques et temporels.

Les critères de recherche sont présentés sous forme arborescente. Ils permettent ainsi une réécriture du référentiel APIDAE, lequel a souvent besoin, selon la structure qui l’exploite, d’être simplifié, de façon à présenter l’information touristique d’une façon accessible au public.
Cette arbre des critères de recherche permet de définir le socle des filtres à facettes qui seront présentés aux utilisateurs finaux.

Il y a donc une relation many-to-many entre les InformationObject et les SearchCriteria et c’est celle-ci qui est exploitée pour permettra le fonctionnement de filtres à facettes rapides et efficaces.
Synchronisation des données : mécanisme au travers duquel les données SynApi sont remises à jour par rapport à leur source sur APIDAE :
- Création, mise à jour et suppressions des fiches,
- Création, mise à jour et suppressions des critères de recherche correspondant aux sélections APIDAE
- Remise à jour du référentiel et des critères internes,
- Génération des caches des Information Objects,
- Génération des caches des relations Objets / Critères,
- Indexation textuelle des contenus,
- Mise en cache physique des médias

Vous souhaitez développer un site internet touristique ? Contactez nos équipes pour organiser une démo basée sur vos données !