Apidae : les enjeux
On travaille avec Apidae depuis 2014, à l'époque où le SIT régional s'appelait encore Sitra. Plus de 25 intégrations livrées depuis : stations de ski, offices de tourisme, parcs naturels, plateformes territoriales. Cette ancienneté change le rapport au SIT. On connaît les contours de la donnée, les pièges classiques d'import, les évolutions de modèle, les nuances entre versions d'API. Ce n'est pas un brief qu'on découvre, c'est un terrain qu'on tient.
On connaît le terrain avant de coder.
Apidae est le système d'information touristique sur lequel s'appuie une grande partie des territoires français. Concrètement, c'est la base où offices, agences départementales et comités régionaux saisissent et tiennent à jour leur offre : hébergements, restaurants, activités, événements, lieux de visite. Chaque objet y est décrit selon un modèle commun, avec ses horaires, ses tarifs, ses coordonnées, ses photos, ses labels, son rattachement à une commune. Cette donnée existe déjà, elle est structurée, et elle est partagée entre acteurs d'un même territoire : ce qu'un hôtelier renseigne sert aussi bien à l'office qu'au comité régional. Pour un site de destination, tout l'enjeu est donc de s'y brancher sans casse, d'en afficher la bonne part au bon endroit, et de la garder vivante sans qu'une personne passe ses journées à recopier des fiches d'un outil à l'autre. Toute la valeur d'un projet Apidae se joue dans cet écart entre une base déjà remplie et un site qui sait en tirer parti.
Le réflexe le plus courant est aussi le plus coûteux : ressaisir. Un office tient son offre dans Apidae pour les obligations du réseau, puis la retape dans le back-office de son site parce que les deux mondes ne se parlent pas. Résultat, deux bases qui divergent dès la première semaine. Un restaurant change d'horaires dans Apidae, le site affiche encore les anciens. Un événement est annulé côté SIT, il reste en ligne côté destination. Le visiteur tombe sur une information fausse, et c'est la crédibilité du territoire qui prend. On part de l'idée inverse. Apidae reste la source de vérité, le site la consomme. La fiche se saisit à un seul endroit, elle se diffuse partout ailleurs. La double saisie disparaît, et avec elle la divergence qui mine la confiance.
Se brancher sur Apidae passe par son API et ses sélections. On définit avec l'office les périmètres qui comptent : tel type d'objet, telle zone géographique, tel ensemble de critères, tel niveau de mise en avant. Apidae renvoie ces objets, le site les récupère et les range dans sa propre structure. La synchronisation tourne en arrière-plan, à une fréquence qu'on cale sur le besoin réel : plusieurs fois par jour pour des disponibilités qui bougent, une fois par nuit pour un fonds d'objets plus stable. Entre deux passages, le site sert une copie locale, ce qui le rend rapide et le protège d'une panne côté source. Si l'API d'Apidae ne répond pas un matin, le site reste debout avec la dernière donnée connue, au lieu d'afficher une page vide. Brancher une plateforme sur un service tiers oblige à prévoir le jour où ce service tombe ; on le prévoit dès le départ. Le périmètre lui-même se pilote depuis Apidae plutôt qu'en dur dans le site : quand l'office ajoute un objet à une sélection ou ouvre une nouvelle zone, le site le récupère au passage suivant sans qu'on touche au code. L'office reste maître de ce qui remonte, on garde la main sur la façon dont c'est servi.
Récupérer la donnée n'est que la moitié du travail. Une fiche Apidae brute n'a pas été pensée pour la page d'accueil d'une destination : elle est complète, normalisée, parfois inégale d'un objet à l'autre selon le soin mis à la saisie. La servir telle quelle, c'est subir le SIT au lieu de s'en servir. On travaille donc la mise en forme. On choisit les champs qui méritent d'être montrés et on écarte le reste, on harmonise l'affichage pour qu'une fiche bien remplie et une fiche minimale tiennent côte à côte sans casser la page, on rattache chaque objet à l'univers graphique du site plutôt qu'à un gabarit générique. Le visiteur ne doit jamais sentir qu'il lit une sortie de base de données. Il lit la destination, et la donnée Apidae travaille en dessous, invisible.
Le filtrage est l'endroit où une intégration Apidae se gagne ou se rate. Un territoire peut compter des milliers d'objets, et personne ne parcourt une liste de cette taille. Il faut donc des entrées qui correspondent à la façon dont un visiteur cherche : par envie, par moment du séjour, par public, par zone, par période pour les événements. Le modèle Apidae porte beaucoup de critères exploitables, encore faut-il les traduire en filtres qui parlent à un voyageur, dans ses mots et selon sa façon de chercher. On conçoit ces parcours avec l'office, on les branche sur les critères réels de la base, et on vérifie qu'une recherche ramène toujours quelque chose d'utile plutôt qu'une page de résultats vides. Un filtre qui ne renvoie rien est pire qu'un filtre absent : il donne l'impression que le territoire n'a rien à proposer.
Apidae structure aussi des liens entre objets, et c'est une matière qu'on exploite trop peu. Un événement se rattache à un lieu, un lieu à une commune, une activité à un prestataire, un objet à des thématiques et à une zone géographique. À partir de ces relations, un site peut composer des pages qui n'existent dans aucune fiche prise isolément : tout ce qu'on peut faire autour d'un site de visite, l'agenda d'une vallée sur un week-end donné, une sélection thématique qui croise hébergement et activité, une page de commune qui agrège son offre complète. La donnée est là, dispersée dans les objets ; le travail consiste à la recouper pour en faire des parcours qui aident le visiteur à se projeter. C'est ce croisement qui sépare un site capable de raconter son territoire à partir de la donnée d'un simple miroir d'export, qui se contente de réafficher les fiches une à une sans jamais les relier.
L'enrichissement éditorial est l'autre moitié de cette histoire. Apidae donne le fond factuel, fiable et tenu à jour, mais il ne donne pas le ton d'un territoire ni son point de vue. Sur un objet, on garde d'Apidae ce qui doit rester juste et synchronisé, les horaires, les tarifs, les coordonnées, et on ajoute par-dessus ce qui appartient à la destination : un texte de présentation écrit par l'office, une mise en avant éditoriale, un rattachement à un itinéraire maison, une photo de meilleure qualité. La fiche affichée devient un mélange : une base Apidae qui se met à jour seule, et une couche d'édition propre au site qui ne bouge que quand l'office le décide. On garde le meilleur des deux mondes sans les confondre, et surtout sans que la couche éditoriale soit écrasée à la prochaine synchronisation.
Quand l'offre dépasse une certaine taille, l'IA peut se poser sur ce socle, mais à une condition stricte : qu'il y ait d'abord une donnée propre dessous. Sur un fonds Apidae bien structuré, une recherche en langage naturel laisse le visiteur formuler une intention floue, du type sortir en famille un jour de pluie, et ramène les bons objets sans l'obliger à empiler des filtres. Une recommandation peut suggérer la suite logique d'un séjour à partir de ce qu'il consulte. Ce sont des couches qui amplifient une donnée déjà saine ; elles ne réparent pas une base mal saisie. Si l'offre reste modeste et qu'un classement clair suffit à faire trouver, on n'ajoute rien. L'IA gagne sa place ici sur un point précis, aider à choisir dans un volume trop grand pour l'œil ; hors de ce cas, elle n'apporte rien qu'on facturerait.
Une intégration Apidae a ses limites, et les nommer fait partie du travail. La qualité de ce qu'un site affiche dépend d'abord de la qualité de ce qui est saisi dans le SIT. Si des fiches sont incomplètes, des photos absentes, des horaires jamais mis à jour côté Apidae, aucun branchement n'y changera quoi que ce soit : le site montrera fidèlement une donnée pauvre. On peut signaler ces manques, masquer les objets sous un seuil de complétude, mettre en avant ceux qui sont bien tenus, mais on ne réécrit pas la base à la place de ceux qui en ont la charge. La saisie reste du ressort de l'office et de ses partenaires. Notre travail commence là où la donnée existe et s'arrête là où il faudrait inventer ce qui n'y est pas. C'est une frontière qu'on pose dès le cadrage, pour qu'un projet ne promette pas une richesse que le SIT ne contient pas encore.
Au fond, brancher un site sur Apidae, c'est arbitrer en permanence entre ce qui doit rester synchronisé et ce qui doit rester éditorial, entre ce qu'on montre et ce qu'on écarte, entre la donnée du réseau et la voix de la destination. Bien fait, l'office saisit une fois et diffuse partout, le visiteur trouve une information juste et présentée pour lui, et le site se nourrit tout seul d'une offre qui vit ailleurs. Mal fait, c'est un export brut recopié sans regard, qui dégrade autant l'image du territoire que l'expérience du voyageur. On construit pour le premier cas : un site qui s'appuie sur Apidae sans le subir, qui en tire une matière vivante plutôt qu'une liste, et qui laisse l'office maître de sa donnée comme de son discours. C'est le seul réglage qui tient sur la durée, parce qu'il sépare ce que la machine doit maintenir de ce qui relève du regard humain sur un territoire.