Sous la responsabilité de la source. Interopérable aux interfaces.

Les connaissances touristiques doivent pouvoir circuler sans perdre le lien avec la source qui peut les tenir à jour, en préciser les conditions et les corriger.

Prenons une maison d’hôtes fictive où un parcours sans marche mène de la cour à la North Room, mais où un seuil de 8 cm marque l’entrée de la salle de bains. La maison d’hôtes consigne ces deux conditions, la date à laquelle elles ont été vérifiées et la personne chargée de revoir la fiche si la chambre change.

Un annuaire peut reprendre une partie de ces informations dans un filtre. Une page consacrée à la chambre peut expliquer à la fois le parcours et le seuil. Avant de décider si la chambre répond à ses besoins, un voyageur peut avoir besoin de mesures complémentaires ou d’une confirmation des conditions actuelles.

Ce sont des usages différents de la même fiche de chambre, pas des réponses interchangeables. L’établissement peut vérifier les caractéristiques physiques des lieux ; cela ne l’autorise pas à décider de ce qui conviendra à chaque voyageur. De même, recevoir la fiche ne rend pas un annuaire responsable d’établir tous les faits concernant la chambre.

L’enjeu consiste à faire circuler les informations utiles tout en maintenant clairement ces responsabilités. Tamaga exprime ce principe ainsi : sous la responsabilité de la source, interopérable aux interfaces. L’organisation peut tenir à jour les connaissances dont elle est responsable, tandis que d’autres personnes et systèmes peuvent en utiliser des représentations adaptées.

Être responsable à la source ne signifie pas enfermer l’information

« Sous la responsabilité de la source » ne signifie pas conserver les informations dans une base de données privée ni obliger chaque voyageur à consulter le site web de l’organisation. Il s’agit de garder la capacité concrète de tenir à jour une fiche approuvée, d’en expliquer les éléments à l’appui et les limites, puis de la corriger lorsque les circonstances changent.

Pour la North Room, la fiche doit distinguer le parcours depuis la cour de l’entrée de la salle de bains. Elle doit identifier la chambre, conserver la mesure et son périmètre, et préciser qui peut la vérifier de nouveau. La maison d’hôtes peut diffuser largement ces informations sans demander à chaque destinataire d’entretenir une version qu’il aurait réinventée de son côté.

Dans cette doctrine, la notion de responsabilité à la source décrit qui répond de la fiche. Elle ne constitue pas une déclaration sur le droit d’auteur, les droits sur les bases de données ou la propriété des données personnelles. Les licences, l’accès, la vie privée et le contrôle contractuel restent des questions distinctes.

L’autorité porte sur une affirmation précise ; elle n’est pas automatiquement accordée à l’organisation décrite. Un hôtel peut tenir les éléments à l’appui concernant ses chambres tout en dépendant d’un opérateur de transport pour les horaires d’un service, ou d’un autre organisme responsable pour la fermeture d’une route. Publier ces informations externes ne doit pas effacer la différence entre ce que l’hôtel établit lui-même et ce qu’il obtient ailleurs.

Le même principe s’applique lorsqu’un voyageur a besoin d’aide pour évaluer une chambre. Le personnel peut fournir des mesures, des photographies et des précisions, puis confirmer ce qui est actuellement présent. Le jugement du voyageur sur ce qui lui convient personnellement ne doit pas être remplacé par une promesse non étayée selon laquelle la chambre lui conviendra.

La responsabilité à la source laisse aussi la place à la contestation. Une fiche approuvée peut être erronée, incomplète ou obsolète. Pouvoir identifier l’organisation responsable de la source doit permettre de la questionner et de la corriger plus facilement, et non la soustraire à l’examen.

Une interface présente une vue des connaissances

Une interface est un point où un autre public ou système rencontre la fiche : une page publique, une fiche d’annuaire, un flux partenaire, une interface de réservation ou une API. Ce qui y circule est une projection, c’est-à-dire une représentation sélectionnée et façonnée pour un usage particulier.

Ces projections n’ont pas besoin d’employer des formulations identiques. Un filtre peut signaler les chambres dont l’entrée est accessible par un parcours sans marche, tandis que la page détaillée explique le seuil de la salle de bains. L’exigence essentielle est que l’affirmation la plus étroite ne devienne pas une affirmation plus large selon laquelle toute la chambre serait sans marche ou adaptée à chaque personne en fauteuil roulant.

Dans cet exemple fictif, une brève description publique pourrait indiquer :

North Room : parcours sans marche de la cour à la chambre. L’entrée de la salle de bains présente un seuil de 8 cm. Consultez la fiche de l’établissement pour connaître la date de la mesure et tous les détails ; contactez la personne qui vous accueille pour obtenir d’autres mesures ou confirmer les conditions actuelles.

Il ne s’agit pas d’une évaluation complète de l’accessibilité. Cette description conserve deux observations précises et un parcours vers des informations complémentaires, sans en tirer un jugement universel sur les personnes auxquelles la chambre conviendra.

Une interface doit donc transmettre suffisamment de sens pour son usage et donner accès à la source suivante lorsqu’elle ne peut pas répondre à la question qui subsiste. Cela n’oblige pas chaque carte à afficher toutes les métadonnées. En revanche, il faut pouvoir retrouver le lien entre une affirmation courte, ses conditions et la fiche qui l’étaye.

Les normes facilitent la circulation de l’information

Une grande partie des mécanismes nécessaires existe déjà. Les Data on the Web Best Practices du W3C recommandent des identifiants persistants, la provenance, les informations de version et de licence, des formats réutilisables et des voies de retour. Ces pratiques concernent la relation entre les éditeurs et les utilisateurs de données, pas seulement la production d’un fichier.¹

Schema.org fournit des termes partagés pour décrire des entités et leurs relations, tandis que JSON-LD permet de sérialiser des données liées dans un format fondé sur JSON.²³ L’approche en monde ouvert de Schema.org distingue également l’omission de la négation : l’absence d’une propriété n’établit pas que quelque chose est faux.⁴ Ces mécanismes aident les systèmes à échanger et à interpréter des informations, mais leur présence ne prouve pas qu’une mesure donnée est actuelle ou suffisante pour la décision d’un voyageur.

La distinction est concrète : un format partagé peut transporter une affirmation ; il ne peut pas remplacer les éléments à l’appui et la responsabilité qui la sous-tendent.

La responsabilité à la source et l’échange sont deux tests distincts

Une fiche peut être bien tenue et difficile à réutiliser. Elle peut aussi circuler efficacement sans que personne sache qui l’a vérifiée en dernier. Assimiler « connecté » à « gouverné » masque ces deux possibilités.

Il faut poser les deux questions séparément :

La première situation constitue l’objectif, pas un certificat de véracité ou d’indépendance. Un service centralisé peut préserver la provenance et les parcours de correction ; une organisation fédérée peut malgré tout laisser les responsabilités dans le flou. Le choix d’une architecture ne dispense pas de décider qui tient chaque affirmation à jour et comment les désaccords sont traités.

La correction doit circuler elle aussi

Supposons que la maison d’hôtes supprime le seuil de la salle de bains et mette sa fiche à jour. Un annuaire affiche encore l’ancienne mesure, alors même que sa connexion aux données de l’établissement reste techniquement disponible. L’observation initiale était peut-être exacte lorsqu’elle a été consignée, mais elle devient trompeuse si l’annuaire continue à la présenter comme actuelle.

Il faut donc examiner l’échange au-delà de la première publication réussie. Le système destinataire doit pouvoir distinguer les versions, découvrir les changements pertinents et actualiser sa présentation. Un lien vers la source aide les personnes à enquêter ; à lui seul, il ne met pas chaque copie à jour.

Le parcours compte aussi dans l’autre sens. Un voyageur ou un partenaire peut remarquer une divergence avant l’organisation responsable de la source. Le signalement doit parvenir à une personne capable d’examiner les éléments à l’appui et, si nécessaire, de modifier la fiche. Les bonnes pratiques du W3C recommandent explicitement de recueillir les retours et de signaler les erreurs à l’éditeur d’origine.¹

Pour Tamaga, il en découle une exigence concrète : l’échange doit ramener les corrections vers la source responsable, puis propager de nouveau vers l’extérieur les changements vérifiés. Un signalement ne devient pas automatiquement une correction approuvée, et la mise à jour de la source ne prouve pas que toutes les représentations qui en dépendent ont été réparées.

Un annuaire peut corriger sa propre présentation sans réécrire silencieusement la fiche approuvée de l’établissement. La maison d’hôtes peut réviser cette fiche sans supposer que l’annuaire a déjà actualisé sa copie. Chaque partie doit avoir une responsabilité claire, et le processus doit montrer ce qui reste à résoudre.

Il ne s’agit pas d’une promesse de synchronisation automatique sur tout l’internet du voyage. Lorsqu’un canal nécessite une modification manuelle, ce travail doit rester visible. Lorsqu’une copie ne peut pas être examinée ou mise à jour, le système doit conserver cette incertitude plutôt que de présenter la correction comme terminée.

La suppression d’un seuil ne doit pas non plus devenir une affirmation non étayée selon laquelle la chambre conviendrait désormais à tout le monde. Une correction doit modifier le fait qu’elle établit, sans s’élargir en une promesse qu’elle ne peut pas soutenir.

Une vérification pratique de la source aux interfaces

Commencez par un fait susceptible de modifier la décision d’un voyageur, plutôt que par l’inventaire de tous les champs de la plateforme. Le seuil d’une chambre en est un exemple ; une condition d’arrivée, une restriction de stationnement, une heure limite pour les repas ou un service de transport saisonnier peuvent remplir le même rôle.

Posez cinq questions :

1. Quelle décision dépend de ce fait ? Repérez ce que le voyageur doit comprendre, pas seulement ce que le système peut stocker.
2. Qui peut l’établir, et dans quel périmètre ? Distinguez les connaissances propres à l’organisation des informations fournies par d’autres et des jugements qui appartiennent au voyageur.
3. Quelles interfaces le réutilisent ? Repérez les pages publiques, les fiches des partenaires et les interfaces où une personne peut rencontrer cette réponse.
4. Quelles conditions et informations sur la source doivent rester accessibles ? Vérifiez les conditions, l’identité et la date nécessaires pour interpréter l’affirmation, qu’elles soient directement visibles ou accessibles par un parcours clair.
5. Comment une erreur est-elle signalée, vérifiée et corrigée dans ces interfaces ? Distinguez le signalement reçu, la source modifiée et la représentation externe mise à jour.

Cette vérification n’exige pas une nouvelle plateforme pour devenir utile. Elle sert à révéler où les responsabilités sont claires, où les informations peuvent circuler et où une correction s’arrêterait aujourd’hui.

Le principe qui sous-tend l’architecture

Sous la responsabilité de la source. Interopérable aux interfaces.

La source doit conserver la capacité de tenir à jour et de corriger les connaissances dont elle est responsable. Chaque interface doit transporter la part dont elle a besoin sans devenir l’autorité pour des questions qu’elle ne peut pas trancher. Lorsqu’une autre réponse est nécessaire, le voyageur ou le système destinataire doit pouvoir déterminer où cette réponse peut être établie.

Pour Tamaga, il s’agit d’un principe de l’infrastructure des connaissances touristiques, et non d’une exigence selon laquelle chaque fait devrait vivre dans une base de données unique ou chaque interaction devrait ramener vers le site web de l’organisation. Le partage et la responsabilité doivent se renforcer mutuellement. Les connaissances peuvent circuler largement tout en conservant des conditions, des sources et des parcours de correction suffisamment clairs pour que d’autres puissent les utiliser de manière responsable.

Le test concret consiste à observer ce qui se passe après une modification de la chambre : la source peut-elle être corrigée, le changement atteint-il les représentations concernées et le voyageur peut-il distinguer la réponse actuelle de celle qui était vraie auparavant ?

---

Périmètre et sources

La North Room est un exemple fictif, et non une évaluation de l’accessibilité ni une observation portant sur un véritable établissement ou une plateforme réelle. La doctrine et la comparaison selon deux axes constituent la position analytique de Tamaga. Les normes citées étayent des mécanismes précis de publication et d’échange ; elles n’établissent ni résultats commerciaux, ni droits juridiques, ni capacité à répondre à des besoins d’accessibilité, ni comportement d’une mise en œuvre en production.

Les normes ci-dessous ont été vérifiées le 22 septembre 2026. DCAT 3 reste une référence pertinente pour les catalogues de jeux de données, les services de données et les métadonnées de version ; il n’est pas présenté comme une exigence pour publier un fait concernant une chambre donnée.⁵

À lire aussi : Qu’est-ce que l’infrastructure des connaissances touristiques ?

Notes de bas de page

1. W3C, Data on the Web Best Practices. Voir les pratiques relatives à la provenance, au versionnage, aux identifiants persistants, aux retours et à la republication, en particulier les bonnes pratiques 5, 7–10, 29, 33 et 35. ↩ ↩²

2. Schema.org et sa documentation destinée aux développeurs, pour le vocabulaire partagé et les définitions lisibles par machine. ↩

3. W3C, JSON-LD 1.1, pour la sérialisation de données liées fondée sur JSON. ↩

4. Schema.org, Style Guide, en particulier la distinction propre au monde ouvert dans « Additional notes ». ↩

5. W3C, Data Catalog Vocabulary, Version 3, pour l’interopérabilité des catalogues et les métadonnées de version des ressources. ↩