Cahier des charges d’un site d’office de tourisme : la partie données SIT, celle qu’on oublie

7 min de lecture

La plupart des cahiers des charges de sites d’offices de tourisme consacrent dix pages au design et trois lignes aux données : « le site devra être connecté au SIT ». Ces trois lignes déterminent pourtant la moitié du coût du projet, l’essentiel des litiges à la recette et la totalité de la maintenance sur cinq ans. Voici ce qu’un cahier des charges doit exiger sur les données touristiques, et comment une agence peut y répondre. Un modèle de paragraphe à copier figure en fin d’article.

Ce que le cahier des charges oublie sur les données

Un site d’office de tourisme affiche des centaines ou des milliers de fiches : hébergements, restaurants, activités, événements, itinéraires. Ces fiches ne sont pas rédigées dans le site ; elles vivent dans le système d’information touristique (SIT) du territoire, Apidae, Tourinsoft ou LEI selon la région, et le site les reçoit. Tout ce qui se passe entre le SIT et l’écran du visiteur relève du cahier des charges : la fréquence de mise à jour, le traitement des fiches supprimées, l’affichage des horaires, l’indexation par les moteurs de recherche, la traduction, la tenue en charge. Quand ces points ne sont pas écrits, chaque candidat les interprète, les offres deviennent incomparables et la recette se fait sur des attentes implicites.

Les questions à poser sur le SIT avant d’écrire

Avant la rédaction, le chargé de mission numérique doit réunir cinq informations et les mettre dans le dossier de consultation.

  • Quel SIT et quel périmètre. Apidae, Tourinsoft, LEI ; le nombre de fiches concernées ; les communes couvertes ; l’existence de sélections ou de flux déjà définis.
  • Quels types d’objets. Hébergements, restauration, manifestations, activités, itinéraires, commerces : la liste conditionne le nombre de gabarits de fiche.
  • Quelle fréquence de mise à jour. Un agenda de manifestations exige une synchronisation quotidienne au minimum ; certains usages demandent la mise à jour à la minute.
  • Quelles langues. Lesquelles sont saisies dans le SIT, lesquelles doivent être traduites automatiquement.
  • Quels autres supports. Si les mêmes données alimentent des brochures PDF, des guides d’accueil ou des écrans, le dire : une solution unique pour tous les supports change l’économie du projet.

Les exigences à écrire

Un cahier des charges n’impose pas une technologie, il impose des résultats vérifiables à la recette. Huit exigences couvrent l’essentiel.

  1. Mise à jour automatique des fiches depuis le SIT, à une fréquence définie, sans intervention de l’office de tourisme.
  2. Suppression automatique des fiches retirées du SIT ou sorties de la sélection : aucune fiche fantôme.
  3. Fiches indexables : une URL lisible par fiche, une balise canonical, des métadonnées compatibles avec l’extension SEO du site.
  4. Dates, horaires et périodes d’ouverture affichés de façon lisible, y compris pour les événements récurrents et les exceptions.
  5. Moteur de recherche multicritères sur les champs du SIT (type, commune, dates, équipements) avec carte.
  6. Multilingue : affichage des traductions du SIT et, à défaut, traduction automatique, avec l’extension de traduction du site.
  7. Tenue en charge : compatibilité avec le cache et le CDN de l’hébergement, purge du cache après mise à jour des données.
  8. Maintenance des évolutions de l’API du SIT, de WordPress et de PHP pendant toute la durée du marché, chiffrée dans l’offre.

La huitième exigence est celle qui départage les offres. Un candidat qui développe un connecteur maison doit chiffrer plusieurs jours par an de maintenance ; un candidat qui s’appuie sur un plugin WordPress Apidae ou Tourinsoft maintenu par un éditeur reporte cette charge sur l’abonnement.

La répartition des rôles

Trois acteurs interviennent, et le cahier des charges doit dire qui fait quoi.

Responsabilité Office de tourisme Agence web Éditeur de la solution de connexion
Saisie et qualité des données Oui, avec son réseau SIT Non Non
Connexion au SIT et synchronisation Non Si développement maison Si plugin
Modélisation et sélection des fiches Oui, dans l’outil Accompagnement Fournit l’interface
Design, thème, intégration Valide Oui Non
Hébergement du site Contractant Oui, le plus souvent Non
Maintenance des évolutions d’API Non Si développement maison Si plugin

Cette répartition évite le scénario classique : des horaires faux sur le site, l’office accuse l’agence, l’agence accuse la donnée, et personne n’a écrit qui corrige quoi.

Modèle de paragraphe à copier dans le cahier des charges

Le texte suivant peut être repris tel quel dans la partie « Données touristiques » d’un cahier des charges, en complétant les crochets.

Le site est alimenté par le système d’information touristique [Apidae / Tourinsoft / LEI] de [territoire], soit environ [nombre] fiches réparties en [types d’objets]. Les fiches sont synchronisées automatiquement au moins [fréquence], sans intervention de l’office de tourisme ; les fiches retirées du SIT sont retirées du site dans le même délai. Chaque fiche dispose d’une URL propre, indexable, avec balise canonical et métadonnées compatibles avec l’extension SEO retenue. Les dates, horaires et périodes d’ouverture sont affichés de manière lisible, y compris pour les événements récurrents. Un moteur de recherche multicritères avec cartographie permet de filtrer les fiches sur [critères]. Le site est disponible en [langues], à partir des traductions du SIT et, à défaut, d’une traduction automatique. La solution de connexion est compatible avec le cache et le CDN de l’hébergement. Le candidat décrit la solution de connexion retenue (développement spécifique ou solution éditeur), précise qui en assure la maintenance et les évolutions d’API pendant toute la durée du marché, et chiffre cette maintenance annuellement. Le candidat précise la répartition des responsabilités entre l’office de tourisme, le titulaire et, le cas échéant, l’éditeur de la solution de connexion.

Comment une agence peut répondre

Face à ce paragraphe, une agence a deux réponses possibles. Développer un connecteur spécifique, et chiffrer honnêtement quinze à trente jours de développement plus la maintenance annuelle. Ou s’appuyer sur une solution éditeur : avec Pylot Bridge, l’agence répond que la connexion au SIT, la modélisation des fiches, la synchronisation, les dates et horaires, le multilingue et la compatibilité cache sont assurés par l’éditeur, que le site reste hébergé et intégré par l’agence, et que l’abonnement démarre autour de 100 € HT par an pour un projet de 100 fiches, ajusté au nombre de fiches. La réponse tient en un paragraphe, et elle couvre les huit exigences. Le détail technique par SIT est sur la page connecter un SIT à WordPress.

Questions fréquentes

Que doit contenir un cahier des charges de site d’office de tourisme sur les données SIT ?

Au minimum : le SIT utilisé et le périmètre des données, la fréquence de mise à jour attendue, les types d’objets à afficher, les exigences d’indexation des fiches, le multilingue, la compatibilité avec le cache et l’hébergement, et la répartition des rôles entre l’office, l’agence et l’éditeur de la solution de connexion.

Qui est responsable de la qualité des données affichées sur le site ?

L’office de tourisme et son réseau SIT, qui saisissent et qualifient les fiches. L’agence est responsable de l’affichage fidèle de ces données, et l’éditeur du connecteur de leur synchronisation. Le cahier des charges doit écrire cette répartition pour éviter les litiges à la recette.

Faut-il imposer une solution de connexion au SIT dans l’appel d’offres ?

Non, mais il faut imposer des résultats : mise à jour automatique, suppression des fiches retirées du SIT, fiches indexables, maintenance des évolutions d’API pendant toute la durée du marché. Le candidat choisit ensuite entre un développement et un plugin, et chiffre la maintenance.

Comment une agence répond-elle à la partie données SIT d’un appel d’offres ?

En décrivant la solution de connexion, sa maintenance sur la durée du marché et la répartition des rôles. Avec Pylot Bridge, l’agence répond que la connexion au SIT, la modélisation et la mise à jour sont assurées par l’éditeur, et qu’elle prend en charge le design, l’intégration et l’accompagnement.

Maquette de site web en fil de fer et liste de contrôle cochée (mise à jour SIT, multilingue, indexation, rôles) : les exigences données SIT d’un cahier des charges
Sommaire

Découvrez d’autres articles

des solutions pour vos enjeux métiers

Prêt à passer en diffusion automatique ?

Découvrez ce que Bridge peut faire pour votre organisation.

Demander une démo

Notre équipe vous rappelle sous 24h.