Office de tourisme : faire exister un territoire en ligne
Un office de tourisme parle pour tout un territoire : hébergeurs, restaurateurs, prestataires d'activités, sites à visiter, événements, producteurs. Personne d'autre ne tient ce rôle d'agrégateur neutre, et c'est ce qui distingue son site d'un site marchand. Le visiteur qui arrive est rarement au même stade que le suivant : l'un rêve encore d'une région qu'il n'a jamais vue, l'autre a réservé et cherche quoi faire samedi sous la pluie, un troisième est sur place et veut le marché le plus proche dans l'heure. À cela s'ajoute un second public qu'on oublie souvent : les habitants, qui consultent l'agenda comme le ferait un visiteur, et les socioprofessionnels du territoire, qui attendent du site un retour concret en visibilité. Un site d'office se construit pour servir ces publics qui n'ont ni les mêmes questions ni le même tempo.
On connaît le terrain avant de coder.
Toute la matière éditoriale d'un site d'office passe par sa donnée. Une grande partie de l'offre vit déjà dans un SIT que les acteurs alimentent eux-mêmes : Apidae en région Auvergne-Rhône-Alpes, un SIT départemental ou national ailleurs. C'est là que se tiennent les fiches d'hébergeurs, les agendas d'événements, les coordonnées et les tarifs. On branche le site sur cette source pour qu'une fiche soit saisie une fois et serve partout, qu'une date annulée disparaisse d'elle-même, qu'un changement d'horaire se répercute sans qu'une personne le retape. Sur le détail de ce branchement, la page Apidae traite le sujet de front ; ici, on rappelle juste que sans cette mécanique propre, un site d'office passe ses journées en double saisie et ses semaines à corriger des informations fausses.
Trois contraintes pèsent sur un projet d'office et cadrent toutes les décisions. L'accessibilité RGAA d'abord : un site financé sur fonds publics doit pouvoir être utilisé par une personne malvoyante, par quelqu'un qui navigue au clavier, par un visiteur peu à l'aise avec un écran. On conçoit dans ce sens dès le départ, parce que rattraper l'accessibilité après coup coûte cher pour un résultat bancal. Le marché public ensuite : ces projets passent presque toujours par appel d'offres, avec un CCTP et des spécifications fonctionnelles détaillées à instruire en amont. On intervient régulièrement en AMOA sur cette phase, pour cadrer le besoin avant la mise en concurrence. Le multilingue enfin : dès qu'une part des visiteurs prépare son séjour dans sa langue, la traduction n'est plus un module ajouté à la fin, elle se pense dans la structure du contenu et dans la mécanique de saisie.
Sur la stack, on raisonne par taille et par nature du contenu structuré. Sur un territoire à fort volume éditorial avec des relations complexes entre objets, types de contenu nombreux et workflows multi-acteurs, Drupal reste un terrain confortable, c'est ce qu'on a porté en 2019 pour le Parc naturel régional du Vercors avec sa plateforme de labellisation des socio-professionnels, branchée sur Apidae. Sur des projets plus orientés vitrine et éditorial, WordPress en headless avec un front Nuxt ou Astro tient très bien, en gardant la souplesse de saisie côté équipes. Dans les deux cas, le branchement au SIT, le multilingue natif et la conformité RGAA sont posés dès le cadrage, pas ajoutés en cours de route.
Un site d'office ne remplit pas les hôtels du territoire, et on ne le promet pas. Il capte l'attention, il oriente, il donne envie, il rend lisible une offre qui vit éclatée chez des dizaines d'acteurs. La qualité de l'accueil, la beauté des paysages et la vitalité des événements appartiennent au territoire et à ses partenaires, pas à son site. Ce qu'on garantit, c'est qu'un visiteur trouve une destination à jour et désirable dans sa langue, qu'un habitant y retrouve l'agenda de la semaine sans tomber sur une date passée, et qu'un socioprofessionnel y voie sa fiche traitée avec les mêmes règles que celle de son voisin. Le reste, l'envie de revenir et le bouche-à-oreille, se gagne sur place.