fév
1
2012

Et si tourisme.fr devenait un site référence ? Épisode 2 : les données… !

Dans ce premier article "Et si tourisme.fr devenait un site référence ?", je vous exposais les grandes lignes encore un peu floues du projet d'Offices de Tourisme de France pour la refonte de tourisme.fr

Cette démarche originale avait pour but de déclencher, des réactions, un débat et des contacts et ainsi en faire presque un projet 2.0 ! Eh bien objectif atteint puisque les échanges ont été "virils mais corrects" comme on dit au Rugby, ou encore "francs et directs" comme on dit en politique...

Pas mal d'idées ont été brassées, des éclaircissements ont été donnés et au delà de l'enfilade des commentaires des contacts directs ont été pris pour faire avancer et évoluer le projet. Soyez sûrs que nous allons étudier les suggestions exposées pour enrichir notre réflexion.

Grâce à cette nouvelle façon de concevoir un projet "ouvert", toute la joyeuse équipe dont je suis le porte-parole espère que les futurs sites de CRT, d'ADT-CDT, d'offices de tourisme ne sortiront plus "de la boîte" tout cuits et démoulés voire parfois malheureusement pas assez cuits et démoulés trop tôt... L'apport d'une communauté turbulente et passionnée ouvre le champ des possibles et donne une consistance nouvelle au concept... Qu'on se le dise... et faites passer le message :-)

Aujourd'hui, j'aimerais en quelques lignes partager avec vous notre première approche concernant l'acquisition et la gestion des données...

 

L'acquisition et la gestion des données pour tourisme.fr ou comment éviter de construire une usine à gaz ingérable...

Pari fou ? Pas si sûr finalement...
Rappelez-vous, le projet présentera trois “entrées” pour l’internaute  :

  • l'entrée "information" → "je sais ou je veux aller et j'ai besoin d'info"
  • l'entrée "motivations" → "je sais ce que j'aime, proposez moi les destinations où je peux trouver ça"
  • l'entrée "recommandations" → "je veux un bon plan, une bonne affaire ou une destination très appréciée de mes collègues touristes, voire de mes amis"

Cela nécessite de disposer des informations sur l’offre touristique française et des suggestions de visites, bons plans, idées de séjours, avis des touristes, etc.
On sait les difficultés inhérentes à la remontée des infos à partir des SIT (Système d'Information Touristique) existants compte tenu de la diversité des outils en place et du nombre de gestionnaires de ces systèmes.
On sait aussi qu’il est impossible de demander aux offices de tourisme de re-saisir les informations dans une base nationale. Il y a donc nécessité de remonter les infos à partir des SIT existants.
Il sera donc incontournable de créer et de gérer un système d’information pour la gestion du site.

Pour y parvenir dans de bonnes conditions, il est nécessaire de simplifier au maximum la base de données à construire pour faciliter le plus possible la remontée des infos des SIT locaux.

Pour ce faire, nous devons réfléchir et innover sur 4 axes :

  1. Quel est le SIT le plus simple pour répondre aux besoins du site ?
  2. Quelle gestion du SIT tourisme.fr faut-il prévoir ?
  3. Quel système de remontée simple et robuste mettre en place ?
  4. Comment convaincre les différents partenaires pour remonter les infos ?
J'aimerais ici concentrer l'exposé sur le point 1 car il conditionne sans doute les solutions possibles pour les 3 autres points.

 

Quel est le SIT le plus simple à construire et alimenter pour répondre aux besoins du site ?

Après un premier balayage rapide des fonctionnalités attendues sur le site, on peut estimer le besoin “minimum” d’info pour un objet touristique comme suit :

  • Identification :
    • identifiant du SIT source
    • identifiant dans le SIT source
    • coordonnées GPS
    • adresse : la commune et le code postal doivent être utilisables pour déterminer des territoires pour servir par exemple au critère “type d’espace” (voir plus bas)
  • Contact :
    • nom de l'OT référent
    • coordonnées mail et téléphone de l'OT référent 
  • Typologie :
    • type d’objet : Hôtel, restaurant, évènement, etc. (on pourrait évidemment se rapprocher des standards type TourinFrance)
    • dates pour les évènements
    • labels (pour pouvoir les mettre en valeur)
  • Thématisation :
    • critères thématiques pour le moteur de “motivations” : un critère “thème” et un critère “type d’espace” 
  • Descriptif :
    • un champ “présentation”
    • un seul champ avec tous les éléments techniques du descriptif (on évite ainsi d’avoir à construire une nomenclature tentaculaire... il faudra bien sûr prévoir quelques règles simples de formatage...) 
  • Liens
    • dispo-résa (la nature de cette info dépendra de la réflexion sur la commercialisation ou non, sur le site lui-même... on l'évoquera dans un article prochain)
    • photos et rich media (on ne remonte pas les contenus, pas la peine de transférer et stocker des milliers de photos...) 
    • associations : suggestions associées/recommandations, séjours, autres
    • fiche détail (à voir si on peut espérer que chaque SIT propose une fiche détaillée pour chaque objet...) 

Voilà une ossature simple. Avec quelques critères techniques d’organisation interne à la base, on peut penser que le besoin se situe entre 20 et 40 informations par objet.
Pour schématiser, on demanderait à chaque gestionnaire de SIT de transmettre pour chaque objet un tableau modèle avec 20 à 40 infos... Cette remontée fera l'objet d'un autre article. 

Cette approche volontairement schématique paraît réaliste. Elle permet toutefois d'imaginer un système d'information simple et semble-t-il suffisant pour répondre aux besoins. Rappelons que le site tourisme.fr aura pour vocation d'engager l'accueil des futurs séjournants, les sites locaux devant prendre le relais pour les demandes les plus fines.

Qu'en pensez-vous ? Je vous remercie de vos remarques et suggestions pour faire avancer le schmilblic :-)

Article précédent Community Manager en office de tourisme : l’interview de Julien Bréal, CM à l’OT de Paris Tous à la campagne ! Tonton Marcel, l’autre tourisme rural Article suivant

Articles similaires

A propos de l'auteur : Paul Fabing

Paul FABING est directeur du RésOT-Alsace (Réseau des offices de tourisme). Architecte de formation, ancien consultant tourisme et chef du service Tourisme de la Région Alsace, il occupe cette fonction depuis 2001. Entre autres missions, le RésOT-Alsace est propriétaire, gestionnaire et animateur du système d’information touristique alsacien qui consolide l’ensemble des informations recensées par les OTSI et de nombreuses structures partenaires.

Plus de 100 sites touristiques institutionnels et publics alsaciens (la totalité en fait), beaucoup de sites nationaux publics et privés, la plupart des éditions papier, les actions de promotion et les outils mobiles s’appuient sur cette base de données pour offrir aux touristes des services fondés sur la même information. Ainsi les OTSI se sont placés au cœur de la problématique touristique alsacienne et occupent une place prépondérante dans le développement de l’etourisme avec comme partenaires le CRT et les ADT notamment.

Promis, il s’efforcera de ne pas rédiger en Alsacien, et apportera sans doute un petit vent d’est raffraîchissant dans ce blog (les Alsaciens ne sont pas aussi sérieux qu’il n’y paraît…).

L’extranet du RésOT-Alsace Alsace.
Email
: pfabing at etourisme.info (cette adresse apparait en toute lettres pour éviter les robots).

  • Anonyme

    Tout est dans le choix !! 

    Faire un choix sur les données à remonter est un pré-requis effectivement, pour ne pas s’engager dans des discussions sans fin. 
    Mais il faut aussi faire un autre choix, celui des objets à retenir. Si on somme tous les objets des SIT en France, on doit être entre 1 et 2 millions d’objet, d’ou la nécessité de faire un choix. 

    On en vient à une notion évoquée à Pau aux #e7, ne pas être exhaustif, c’est définir des incontournables. Qui les définira ?

    • Pfabing

      Oui, il faudra être sélectif… Cela dit, on est sur le site national qui peut/doit s’appuyer sur tous les sites d’offices de tourisme. Donc l’exhaustivité est à l’étage suivant.
      La « selection » des objets se fera d’abord sur certains critères objectifs repérables dans les SIT locaux et on échappera pas à un travail éditorial au niveau national, qu’il faudra de toute façon mener pour « taguer » chaque objet pour caractériser les logiques motivationnelles.

      • http://www.medium-message.com Vincent Vandevelde

         »
        La « selection » des objets se fera d’abord sur certains critères objectifs repérables dans les SIT locaux et on échappera pas à un travail éditorial au niveau national, qu’il faudra de toute façon mener pour « taguer » chaque objet pour caractériser les logiques motivationnelles. »

        C’est la clé, et c’est là que sera le gros du travail. Des millions d’objets vont remonter, des tris automatiques pourront être mis en place mais pour éditorialiser et sortir les objets inintéressants à l’échelle nationale il va falloir du monde derrière les écrans…Ou alors vous prenez de la donnée « brute » mais l’intérêt pour le visiteur et les usages possibles de ces données seront limités.

  • Eckjoseph
    • Jean-Luc Boulin

      Monsieur Eck, merci de ne pas spammer les commentaires avec un lien sur un site internet valorisant votre gîte. Un conseil : Passez plutôt du temps à parcourir les pages de ce blog qui vous donneront des conseils pour améliorer votre présence sur le web et soigner votre image (les pages perso skyrock, franchement, c’est pas top pour séduire les clients…)

  • Fredleput

    Une google map et ça suffirait amplement…
    je suis pour la réduction des coûts

  • http://www.christophebenoit.com/ Christophe BENOIT

    Bien penser à un outil d’import souple afin de s’adapter aux différents SIT déjà installés (et pas forcément évolutif).
    Si les SIT locaux n’ont pas à apporter de changements sur leurs outils propres, c’est déjà une contrainte de moins…

  • http://twitter.com/TdF__ademe gabriel plassat

    bonjour, vous pouvez également intégrer dans les critères de choix et/ou les résultats des propositions, des estimations énergétiques et environnementales en fonction des modes de transports utilisables pour se déplacer. Il existe un Appel à Manifestation d’Intéret (AMI) sur le sujet des mobilités occasionnelles lancé par l’ADEME dans le cadre des Investissements d’Avenir : voir http://transportsdufutur.typepad.fr/blog/2011/12/ami-cha%C3%AEnes-logistiques-et-mobilit%C3%A9s-occasionnelles-des-personnes-ademe.html

  • http://www.facebook.com/people/Emmanuel-Bréton/762784144 Emmanuel Bréton

    Bonjour, 

    La recherche d’information dans la communauté est effectivement originale et plein de promesse. Bravo pour cette initiative.

    Je me réjouis donc de lancer ma pierre dans la mare : partager mon expérience sur la gestion de projets web, et les risques de tomber dans une approche trop traditionnelle.

    Et si l’introduction de l’article n’est pas traditionnelle, la suite l’est. 

    Vouloir définir une solution ‘papier’ pour un problème web n’est pas adapté. Un projet web doit se concentrer sur des fonctionnalités
     * si possible existantes
     * à valeur ajoutée pour l’utilisateur
     * les valider en mode itératif. 

    L’expérience m’a montré que le temps ou l’on définissait un model de base de données en ouverture de projet n’est plus en adéquation avec les contraintes web actuelles :  * incertitude des réels besoins des utilisateurs * réactivité et vitesse de développement

    L’article parle des internautes, puis des Offices de Tourismes. Mais qui est l’utilisateur final ? L’internaute ou l’OT ? La description du modèle répond ‘OT’ puisque le données sont formatées en fonction des Système d’Information Touristique. Mais j’ai plutot envie de répondre que l’utilisateur final est l’internaute. 

    Et si tourisme.fr doit présenter un contenu qui a été formaté en fonction des besoins des OT… va falloir jongler. Et jonglage 
    => problème de performance + maintenance 
    => problème de charge (entre autres)
    => problème pour un site national

    Nous avions ce genre de soucis chez Edipresse (Editeur des quotidiens suisses romands) et les avons résolus en choisissant d’abord le CMS et en l’adaptant ensuite aux besoins métiers. Avec un succès étonnant. L’expérience complète est décrite dans un long récit ici:
    http://www.media-business.biz/content/webfactory-edipresse-retour-sur-une-success-story-de-3-ans

    Je résume les quelques leçons explicites de cette histoire si l’article vous fait peur:

     * les risques des prestataires : « internalisation des compétences core-business »
     * l’importance du socle technique : « produit open source performant »
     * la vitesse de développement : « Plus de 27 sites produits en 3 ans »

    Les quelques leçons sous-jacentes :

     * un site est remplacé ou « refondu » tous les deux ans s’il veut rester viable : cas extrème avec lematin.ch qui a connu 5 refontes complètes en 5 ans, sous 4 CMS différents
     * l’avant-projet doit se concentrer sur l’adaptation de fonctionnalités disponibles pour aller au plus vite sur le développement

    Je pense que mon commentaire a déjà bien dépassé la longueur maximale tolérée par l’internaute et touche à la limite de celle tolérée par l’auteur. Je ne voulais pas juste écrire ‘attention mur’ mais expliciter un peu mon propos. 

    Ma recommandation serait d’étudier quels sont les outils existants répondant (en partie) à vos besoins et de partir de là. Le premier commentaire proposait google map. Ce  n’est bien sur pas adapté à l’ensemble de votre propos.. mais c’est l’idée !

    Cordialement,
    Emmanuel Bréton


Recevez notre actualité

Recevez toute l'actualité !

Suivez nous sur Facebook

Suivez nous sur Twitter