France's DATAtourisme shows what locally maintained tourism information can become. The harder question for Québec is keeping it useful, infrastructure alone doesn't do that.
Imagine a tourism business changing its opening hours for autumn. The team knows the new schedule, but the member listing and the other channels visitors read have not caught up. The challenge is not storing the information. It is getting a verified update to the places visitors consult.
That is an illustration rather than a documented case, but it describes a familiar coordination problem. For a tourism organization maintaining information from many member businesses, it can become a recurring one.
One qualification belongs at the top. The database already exists, and that does not fix anything.
The Government of Québec runs SIT Québec, a platform built to manage and distribute the tourism data supplied by tourism organizations, and to promote products and services to people using Bonjour Québec, to the ministry's visitor-information network, and to tourist information offices across the province.
Structured datasets are also published through Données Québec in JSON, XML, and CSV.
There is an honest qualification. Several of those datasets describe themselves as an overview of the tourism offering rather than an inventory of it. The restaurant dataset, for instance, states plainly that it is an aperçu of Québec's tourism offering and is not intended to record the offering in its entirety. That is a scope limit stated by the source itself. It is not evidence that the information is inaccurate or badly structured. It means nobody claims to have covered everything, which is the ordinary condition of any large information system.
So the infrastructure is in place. The question is how information reaches it, how it stays current, and how it gets back out.
Most arguments about tourism data are really arguments about one of these five.
Completeness means the necessary details are present. Freshness means those details still reflect reality. Structure means the information is organised consistently rather than described in prose. Validation means the responsible people check it. Reuse means it can serve more than one authorised channel.
A listing can contain every required field and still describe last season's offering.
Tourism businesses know their own offering better than anyone. An inn knows its hours, its themes, its booking conditions. A guide knows the routes, the seasons, the group sizes.
Keeping that information current across forms and portals competes with the day-to-day work of running a business.
So the work comes back to the organisation. A team follows up, receives an explanation in ordinary language, transcribes it into the fields it knows, checks it, and enters it again somewhere else. When updates arrive as scattered messages, clarification is needed, details must be written into structured fields, and someone has to determine where each change must be distributed.
This is not a failure of the tourism organisation. It is doing what it can with the tools available. It is a predictable friction in how information is contributed.
For a visitor comparing activities, the practical details are what make a choice possible: opening hours, dates, location, services, booking information. When those details are missing or conflict with one another, an option becomes harder to assess, and the visitor moves to a listing that answers the question.
This matters more than it used to. Decisions increasingly start with a search or a question to an assistant, on a phone, before anyone calls. Travel planning tools and conversational assistants read the published description of a destination and recommend from it. A listing that is incomplete or out of date is therefore not merely untidy, it is information the decision points of a trip may never reach. Conversely, a listing that is current and structured is easier to find, easier to compare, and easier to trust.
That is the mechanism worth being precise about. It is not that a database wins rankings. It is that a destination whose listings are current is legible to the tools people actually use when they choose, while one whose listings have drifted is quieter, harder to compare, and more likely to lose attention to a competitor that has kept up.
For the tourism team, the same data problem arrives as time. Repeated clarification and data entry take hours that could have gone to supporting members and promoting the destination. Freeing that time is not a revenue claim; it is capacity returned to the work that promotes the region.
These are operational risks worth addressing, and they are plausible mechanisms rather than measured outcomes in Québec. Nothing in this article should be read as evidence of a measured loss of bookings, and no figure is offered for one.
France runs DATAtourisme, a national platform that aggregates tourism information from more than forty territorial tourism databases, normalises it into a common format and vocabulary, and makes it available for reuse by third parties.
Two things about that are worth stating precisely. The platform does not replace the local systems: its own FAQ is explicit that DATAtourisme is not a SIT, and positions it as a distribution channel between territorial databases and the services that reuse them. And France is not an example of clean data. Each producer keeps control of their own data and decides the pace and scope of what they publish.
The clearest reuse case is Cartes IGN. On 9 July 2026, DATAtourisme announced that tourism events distributed through the platform had become available in the Cartes IGN application, with daily updates and no additional data entry required from the tourism offices and committees that produced them.
What that shows is narrow and worth stating narrowly. Information maintained locally reached an additional service without being re-entered. It does not show an increase in bookings, an effect on spending, or any advantage France holds over Québec. The sources reviewed for this article do not establish that these systems make France more competitive than Québec, and a national platform and a provincial system are not directly comparable in scale or governance.
The transferable part is small, and it is about maintenance rather than about any national platform. One structured update, made once, can reach more than one service. Every additional channel that has to be fed by hand is another place where information drifts out of date, and the effort spent keeping several channels aligned is effort not spent on the destination itself.
That is the part worth carrying to a regional organisation. It is not a ranking argument. It is a claim about how much upkeep a given structure demands, and how much of a team's attention that upkeep takes away from everything else.
ISOD Enrichissement is designed to let member businesses describe an update in their own words, and to prepare structured information that the tourism organisation can review. A proposed pilot would define the scope, the validation responsibilities, and the integration arrangements before the workflow was evaluated. It is a product concept today, with a pilot to be scoped.
It is not a database of traveller personal information. It concerns information about tourism businesses and their activities: accommodation, attractions, activities, services, and events. Businesses contribute, tourism teams validate, and existing systems keep their role.
It is designed to complement SIT Québec and Tourinsoft rather than replace them, and it does not require rebuilding an organisation's website. Integration details still have to be scoped, available interfaces, permissions, how fields map across systems.
The intended benefits are three. For member businesses, an easier way to explain a change. For tourism teams, better-organised information to review. For the destination, a stronger foundation for keeping information useful across its channels. These are intended benefits, not measured results.
The member explains. The business describes its offering or a change, in ordinary language.
ISOD helps clarify. The interaction identifies what is missing or ambiguous and asks for it.
The information is structured. The update is organised into fields useful to the organisation's workflow.
The organisation validates. Its team retains control, under agreed review rules.
The information enters existing systems. Transfer arrangements are defined by interface, permission, and requirement.
This is a proposed workflow rather than a production deployment. The intent is that missing information is flagged for confirmation rather than filled in with assumptions.
An illustrative case: a business says it will offer guided visits on autumn weekends. The workflow would ask for exact dates, days, and hours, then prepare structured fields for review. That is an illustration of the intended experience, not a customer case.
A useful pilot starts with a baseline, the current state of the listings, before anything changes.
A proposed pilot would compare, before and during the trial, the completeness of listings, the freshness of the information, the participation of members, the time spent on follow-ups, the time spent reviewing and validating updates, and the conditions and limits that affect wider adoption.
Scope, cohort, and indicators would be agreed with the organisation before starting. A target agreed in advance is not a result, and this article does not offer one.
Structured, verified information is the practical foundation of a destination's digital presence. It is what lets a destination be found by the tools people use when they plan a trip, compared without ambiguity, and trusted on the details that determine whether a visit happens. That foundation is worth building carefully. It is not a ranking, and it is not a revenue line.
What it does not do is guarantee an outcome. Better-organised information can support search, filtering, and distribution. It does not guarantee search rankings, inclusion in AI assistant answers, or more bookings, and this article offers no figure for any of those.
And the scope of the proposal is narrow on purpose. ISOD Enrichissement addresses how businesses contribute updates and how teams validate them. It is not a claim to solve every tourism data problem, and the infrastructure it complements is the Government's, not ours.
The next improvement is not only technical. It also concerns how businesses contribute updates, how teams validate them, and how approved information moves between systems.
If you are responsible for maintaining your members' tourism information, Storyline would be glad to discuss how a pilot could be scoped around your listings, your validation process, and measurable objectives.
The workflow set out above is the one the consortium product ISOD Enrichissement is built around, its page sets out the proposed pilot scope and what integration with existing systems would involve.
It does. SIT Québec is a Government of Québec platform that brings tourism information together and distributes it to Bonjour Québec, visitor-information services, and participating partners. The open datasets published through Données Québec describe themselves as an overview of the tourism offering rather than an exhaustive inventory. The open question is not whether the infrastructure exists, it is how member updates reach it and stay current.
That structured information can reach additional services without being entered again. In July 2026 DATAtourisme announced that tourism events distributed through its platform had become available in the Cartes IGN application, with daily updates and no additional data entry required from tourism offices. It demonstrates reuse and distribution. It does not demonstrate a change in bookings, spending, or competitive position.
It is a product concept, with a pilot still to be scoped. A proposed pilot would define the scope, validation responsibilities, and integration arrangements before the workflow is evaluated. It is designed to complement existing infrastructure such as SIT Québec and Tourinsoft rather than replace it.
