AI Cities pour les apps de tourisme : douze villes déjà câblées, une intégration et le produit voyage que vous pouvez livrer

Depuis qu'AI Cities est en ligne, la question qu'on me pose a changé de forme. C'était « qu'est-ce qu'un Connector ». C'est maintenant « est-ce que je peux construire un produit là-dessus », et ceux qui demandent ne sont pas des gens de plateforme. Ils dirigent des organismes de marketing de destination, ils construisent des planificateurs de voyages, ils opèrent des produits de conciergerie hôtelière, et ils arrivent tous avec le même tableur : la liste des APIs qu'il faudrait intégrer pour couvrir correctement une seule ville.

Ce poste répond avec un inventaire, une architecture, et les parties qui sont dures. La version courte : le tourisme est le domaine où une ville câblée correspond presque un pour un à un produit grand public. Un voyageur touche six des huit systèmes d'une ville dans les soixante-douze premières heures, chacun de ces contacts est déjà une lecture en direct, et l'intégration que vous auriez écrite pour une ville est la même intégration pour douze.

Pourquoi le tourisme est la première surface produit d'une ville câblée

Sur AI Cities, une ville est organisée en huit systèmes : mobilité, énergie, environnement, services publics, culture, géographie, commerce et sécurité. C'est ainsi qu'une ville se pense. Ce n'est pas ainsi qu'un visiteur pense, et l'écart entre les deux est l'endroit où vit un produit de voyage.

Prenons un visiteur à Amsterdam pendant trois jours. La mobilité, c'est la station de vélos partagés, le tramway, la zone où il ne se garera jamais deux fois. La culture, c'est ce qui se passe ce soir et s'il reste encore deux billets. L'environnement, c'est la bande de pluie qui arrive à neuf heures et l'air au bord de l'eau. Les services publics, c'est l'adresse, le dossier du monument, le jeu de données ouvert derrière les deux. La géographie, c'est la distance, l'altitude, l'itinéraire qui évite la côte. Le commerce, c'est le prix et la carte. La sécurité, c'est le chantier qui ferme l'itinéraire du canal à six heures.

Six des huit systèmes d'une ville, croisés le premier jour, sans que le visiteur apprenne jamais le nom d'un système. Aucune autre catégorie de produit ne touche une ville aussi largement et aussi vite.

La deuxième raison, c'est la forme de la charge de travail. Le tourisme lit beaucoup et écrit peu. Un visiteur pose mille questions et réserve une poignée de choses, ce qui est la charge de travail idéale pour un plan de données qui lit en direct et, quand un Connector peut agir, agit sur un service plutôt que sur la ville. Notre contrat sur la page AI Cities est explicite : rien ici ne donne à un agent le contrôle des infrastructures publiques. Pour un produit de voyage, ce n'est pas une limite, c'est le contrat correct.

La troisième raison, c'est l'arithmétique. Chaque produit de voyage que j'ai examiné porte la même ligne cachée : les intégrations. Une ville couverte correctement signifie transports en commun, vélos en libre-service, stationnement, météo, qualité de l'air, événements, billetterie, géocodage et le portail de données locales ouvertes, chacun avec sa clé, sa limite de débit, sa forme d'erreur, et son jour de changement. Multipliez par les villes visées et vous avez la raison pour laquelle la plupart des produits de voyage s'arrêtent à trois marchés.

L'inventaire honnête : ce qui est réellement câblé

Douze villes sont en ligne en bêta : Amsterdam, Berlin, Lisbonne, Londres, Madrid, Moscou, New York, Paris, Rio de Janeiro, San Francisco, Singapour et Tokyo. Chacune est adossée à des Connectors vers ses propres systèmes, pas à un flux mondial générique.

Amsterdam est la plus complète, c'est donc celle que je cite précisément : huit systèmes en ligne avec 40 Connectors. Côté mobilité : CityBikes pour le vélos en libre-service, TomTom Parking Availability, Google Maps, Mapbox, Uber, et le jeu de données Parking et Zones de trafic de la ville, sans clé. Côté culture : les archives du Rijksmuseum, Eventbrite, Ticketmaster, Bandsintown, et le jeu de données de la ville sur les événements, les lieux et le sport. Côté environnement et sécurité : AccuWeather, AirVisual, AQICN, OpenWeather, Open-Meteo, le flux d'incidents de la ville pour les pannes et les chantiers, et les prévisions d'inondation du Global Flood Awareness System. Côté services publics : l'explorateur DSO avec plus de 122 jeux de données, le registre d'adresses BAG, les calendriers de déchets et de recyclage, et le portail de données ouvertes de l'EU.

Relisez cette liste : le mélange est le point. À peu près la moitié sont des APIs commerciales avec un compte derrière, à peu près la moitié sont les registres de la ville, accessibles sans clé API. Un produit de voyage a besoin des deux : les flux commerciaux donnent la couverture et la qualité, les flux municipaux donnent ce qu'une seule ville sait : le quai fermé, l'arbre tombé dans la tempête.

Deux règles vont avec cet inventaire, et je les imposerais à toute équipe. La première : la page de la ville indique quels systèmes sont câblés et lesquels sont encore en cours de connexion, donc vous vous engagez sur ce qui existe plutôt qu'à une feuille de route. La deuxième : tout y est une lecture en direct au moment où vous demandez. Rien n'est mis en cache, donc votre produit ne peut pas publier un horaire périmé et blâmer la plateforme.

Ce n'est pas une autre API de voyage

Le voyage a des APIs depuis des décennies. Le monde d'Amadeus et Duffel, la lignée des GDS, résout l'inventaire : sièges, tarifs, réservations, échanges. Il est excellent sur la transaction et ne connaît rien de l'endroit. Ces APIs peuvent vous dire quel vol atterrit à 14:00. Elles ne peuvent pas vous dire que la route de l'hôtel ferme à six heures, que l'AQI le long du corridor monte, ou que le seul concert de ce soir est à trois arrêts.

La couche ville répond à ce deuxième ensemble de questions ; les deux sont complémentaires, pas concurrents. Un produit qui a le tarif mais pas la rue est un moteur de réservation. Un produit qui a la rue mais pas le tarif est un guide. Le produit intéressant a les deux, et jusqu'ici avoir les deux signifiait posséder deux programmes d'intégration avec deux courbes de maintenance.

C'est le vrai changement. Les APIs de transaction allaient toujours être une commodité que vous louez. Le côté ville n'a jamais été disponible comme commodité du tout : vous intétriez une municipalité, ou vous n'aviez pas les données. AI Cities rend le côté ville louable de la même manière, avec le même schéma d'appel, pour chaque ville qui est câblée.

L'architecture : une intégration, douze villes

Sous le capot, chaque Connector est exposé sur MCP, le protocole ouvert parlé par les assistants que vous utilisez déjà. Votre application est identifiée par une paire de clés créée une seule fois dans le tableau de bord : un app id public et une clé d'application secrète. Vous adressez vos voyageurs par l'id que vous leur assignez déjà, et pour chacun le SDK renvoie un accès scopé vers les systèmes de ville qu'il a connectés. Vinkius provisionne la connexion, détient les identifiants et exécute derrière un plan de données gouverné. Votre code ne porte aucune clé amont, aucun flux OAuth, aucune boucle de retry par ville.

L'unité de portée est le voyageur, pas le tenant, et c'est la décision de design que je défendrais le plus fort dans un produit de voyage. Une conciergerie qui peut modifier la réservation de quelqu'un n'est sûre que lorsque la réservation qu'elle touche appartient à la personne qui demande. Les Connectors de chaque voyageur sont des connexions isolées avec leurs propres jetons, énumérées et exécutées dans leur propre runtime, facturées séparément et arrêtées séparément. L'isolation est imposée par la forme du chemin de données, pas par un document de politique.

Voici la boucle, tirée de l'exemple du SDK, avec les systèmes de ville du voyageur comme jeu d'outils :

import OpenAI from 'openai';
import { Vinkius } from '@vinkius/connect';
import { toOpenAITools, runOpenAIToolCall } from '@vinkius/connect/openai';

const openai = new OpenAI();
const MODEL = process.env.OPENAI_MODEL ?? 'your-model-id';

const vinkius = new Vinkius({
  appId: process.env.VINKIUS_APP_ID!,
  apiKey: process.env.VINKIUS_APP_KEY!,
});

export async function concierge(userId: string, question: string) {
  const caps = await vinkius.user(userId).capabilities();
  if (caps.length === 0) {
    return 'Connect a city first and I can answer that live.';
  }

  const tools = toOpenAITools(caps);
  const messages = [{ role: 'user', content: question }];

  for (let step = 0; step < 4; step++) {
    const reply = await openai.chat.completions.create({ model: MODEL, messages, tools });
    const msg = reply.choices[0]?.message;
    if (!msg?.tool_calls?.length) break;

    messages.push(msg);
    for (const call of msg.tool_calls) {
      const result = await runOpenAIToolCall(caps, call, {
        idempotencyKey: `${userId}:${call.id}`,
      });
      const text = result.content.map((c) => c.text).join('\n');
      messages.push({
        role: 'tool',
        tool_call_id: call.id,
        content: result.isError ? `The tool reported an error: ${text}` : text,
      });
    }
  }

  return reply?.choices[0]?.message?.content ?? '';
}

Aucun code spécifique à une ville dans cette fonction. Elle ne sait pas qu'elle est à Amsterdam. La ville arrive via les capacités que le voyageur a connectées : la même fonction sert douze villes et la treizième sans branchement.

Exemple détaillé : une question, cinq systèmes

« Nous atterrissons à 14:00 avec un enfant et une poussette. Où dînons-nous ce soir près du musée, et comment on y va s'il pleut ? »

Suivez ce qui doit se passer avant que cette réponse ne soit honnête :

1. Résoudre l'hôtel et le musée en coordonnées. Géographie : LocationIQ ou OpenCage.
2. Lire la bande de pluie et la qualité de l'air pour cette fenêtre. Environnement : Open-Meteo et AccuWeather, AQICN pour le corridor.
3. Lire ce qui se passe ce soir près de cette adresse, et s'il reste deux billets. Culture : le jeu de données d'événements de la ville, Eventbrite, Ticketmaster.
4. Consulter le flux d'incidents pour l'itinéraire que vous alliez recommander. Sécurité : le connecteur de statut et d'incidents de la ville.
5. Choisir le déplacement : les vélos au stationnement, le tramway, ou le stationnement près du lieu. Mobilité : CityBikes, TomTom, Google Maps.

Cinq systèmes, une conversation, et le voyageur n'a jamais installé quoi que ce soit. Chaque étape est un appel d'outil choisi par le modèle, chaque résultat est une lecture en direct, et chaque appel atterrit dans la piste d'audit avec l'id du voyageur. Si l'étape quatre revient avec un quai fermé, la réponse change avant l'envoi, pas quand le client est déjà sur place.

Ce qui est difficile, dit simplement

La variance par ville est réelle. Amsterdam a huit systèmes câblés avec 40 Connectors. Une autre ville peut être en ligne sur la mobilité et l'environnement alors que les services publics sont encore en cours de connexion. La réponse d'ingénierie est d'énumérer les capacités au runtime et de concevoir pour un ensemble qui change, pas de hardcoder une matrice de villes. La réponse côté utilisateur est l'honnêteté : dire ce qui est disponible, et où.

La fraîcheur, c'est toute la promesse. Un produit de voyage vit ou meurt selon le fait que le tramway tourne. Les lectures se font au moment de la demande, donc le mode de défaillance pour lequel vous concevez n'est pas des données périmées, c'est l'amont brièvement indisponible. Traitez les échecs d'outil comme des résultats plutôt que des exceptions, et laissez le modèle dire qu'il ne sait pas pour l'instant au lieu d'inventer une heure de départ.

Les actions sont étroites volontairement. Quand un Connector peut agir, il agit sur le service : maintenir une réservation, réserver une place. Il n'agit jamais sur les infrastructures publiques. Construisez autour des lectures et de quelques écritures explicites et vous ne rencontrerez jamais la limite. Concevez un produit qui suppose pouvoir décaler les horaires des transports d'une ville et vous avez conçu quelque chose qui ne peut pas être livré.

Chaque appel est consigné. Tout cela tourne sur Vinkius : exécution V8 isolée par connexion, plus de 34 règles de sécurité, une piste d'audit signée de chaque action, des limites de dépense qui se mettent en pause plutôt que de surprendre, et un interrupteur qui arrête tous les agents. Pour un produit de voyage grand public, c'est la différence entre « notre AI a fait quelque chose de bizarre la nuit dernière » et un reçu qui nomme l'outil, le voyageur et l'horodatage. Le plan de contrôle, avec la source, est couvert dans AI Governance : le plan de contrôle derrière chaque appel d'outil de vos agents, et le sandbox lui-même dans Zéro cold start pour le code non de confiance.

Quatre produits que vous pouvez livrer ce trimestre

Une conciergerie de journée de voyage. Chat d'abord, pas de téléchargement, pas de connexion par service. Pluie à neuf heures, vélos au stationnement devant le bureau, billets pour deux avant le dîner, dernier train à 22:50. Chaque entrée de cette conversation est une lecture en direct que vous avez déjà.

Un routeur sensible au confort et à l'accessibilité. L'itinéraire qui évite la côte, le corridor à AI élevé, le quai fermé et les marches de la gare. Qualité de l'air, altitude, incidents et itinéraire sont des Connectors séparés, les composer est le produit, et aucune app de cartes en place ne les compose.

Un back-office de destination. Pour un organisme de marketing de destination ou un groupe hôtelier : les événements du jour, les lieux de ce soir, les jeux de données ouverts et le flux d'incidents, alimentant un site ou un assistant qui répond dans la langue du visiteur au lieu d'une page statique mise à jour au printemps dernier.

Une couche ville pour une plateforme de voyage existante. Si vous avez déjà les utilisateurs et les réservations, le levier est différent : une intégration, et chaque ville câblée devient un marché que vous pouvez ouvrir sans nouveau projet d'intégration.

La construction commence là où le câblage s'arrête

La démo d'AI Cities, c'est poser une question sur une ville à votre assistant et obtenir une réponse en direct. Ce n'est pas le produit. Le produit, c'est ce que vous construisez sur les mêmes Connectors, pour des voyageurs qui ne sauront jamais qu'il y avait un protocole en dessous.

Commencez par l'index AI Cities, ouvrez la ville qui vous intéresse, et lisez quels systèmes sont en ligne aujourd'hui. Puis câblez-la avec le AI Connect SDK et construisez l'application locale qui aurait dû exister.