Making-of
Andiamo : un comparateur de voyages qui n’a pas d’écran
Le produit ne vit pas sur une page. Il vit dans ChatGPT et dans Claude, où l’utilisateur n’a ni formulaire, ni filtre, ni carte : seulement une phrase. Tout ce qu’on contrôle, c’est ce que le modèle lit.
Rôle Looptra
Produit, agrégation de données, exploitation
Statut
En production
Terrain
Voyageurs, dans ChatGPT et Claude
Socle
Serveur MCP, train, bus, aérien, horaires GTFS
Section 01
Le problème réel
Comparer un train, un bus et un avion demande d’ouvrir cinq sites qui ne parlent pas la même langue. Chacun répond gare à gare ou aéroport à aéroport, alors que le voyageur part de chez lui et va chez quelqu’un. L’heure affichée n’est jamais l’heure à laquelle il arrive vraiment : il manque le trajet jusqu’à la gare, le battement, et le dernier tronçon.
Le comparateur classique impose en plus son interface : un formulaire, des onglets, des filtres qu’il faut apprendre. Or la demande réelle tient en une phrase, avec ses contraintes dedans : « je dois être à Chamonix vendredi midi ». C’est cette phrase qu’on a décidé de prendre comme entrée, sans la faire passer par un écran.
Section 02
La contrainte dure
L’interface, c’est de la documentation
Il n’y a pas de bouton à déplacer, pas de libellé à corriger après un test utilisateur. Ce que voit l’utilisateur dépend de ce qu’un modèle de langage a compris de nos descriptions d’outils, puis a choisi de reformuler. Le texte technique n’est plus une annexe : c’est le produit.
Porte à porte, ou rien
Un horaire de train qui ignore les quarante minutes d’accès à la gare et les vingt kilomètres d’arrivée ne répond pas à la question posée. Il faut donc chaîner de l’approche, un battement, un trajet longue distance et un dernier tronçon, à partir de sources qui ne se connaissent pas entre elles.
Chaque réponse a un coût variable
Les horaires ferroviaires viennent de l’open data, l’aérien passe par une API payante. Un assistant qui explore librement peut déclencher dix recherches là où l’utilisateur en attendait une. Le coût d’une conversation n’est pas prévisible à l’avance : il faut le borner dans le produit.
Section 03
Les décisions, et ce qu’elles coûtent
La composition du trajet se fait chez nous, pas dans l’assistant
Pourquoi : en n’exposant que « cherche des trains » et « cherche des bus », c’est le modèle qui recolle les morceaux — et il oublie l’accès à la gare, le battement, le dernier kilomètre. Un seul outil résout les deux lieux, interroge les modes en parallèle et rend des stratégies déjà comparables, chacune avec son détail de score.
Ce que ça coûte : un outil lourd et plus lent qu’un appel simple, dont la logique métier doit être tenue à jour par nous seuls.
Un score unique entre des modes qui n’ont rien de comparable
Pourquoi : temps, prix, risque de correspondance et confort sont ramenés à une note commune, avec un arbitrage explicite selon qu’on cherche le plus rapide ou le moins cher. Sans ça, la réponse est une liste, et une liste n’est pas une recommandation.
Ce que ça coûte : des arbitrages qu’on assume publiquement, y compris quand un train gratuit passe derrière un bus payant. Le détail du score est donc affiché plutôt que caché.
Une donnée incertaine doit se signaler elle-même
Pourquoi : le dernier tronçon est soit un horaire publié, soit une hypothèse quand plus aucun service ne dessert la destination après ce train. La réponse porte le statut de la donnée, et demande explicitement à l’assistant de le dire au voyageur. Un modèle qui lit un chiffre sans étiquette le présentera comme une certitude.
Ce que ça coûte : des réponses moins nettes que celles d’un comparateur qui affirme tout. On préfère un « arrivée estimée, à vérifier » à un bus inventé.
La voiture est chiffrée, mais hors classement
Pourquoi : durée hors trafic, distance, carburant au prix relevé du jour, péage quand une grille le couvre. C’est le point de comparaison que le voyageur a en tête de toute façon. Le mettre dans le classement reviendrait à recommander un trajet qu’on ne sait pas réserver ; l’omettre reviendrait à laisser la question sans réponse.
Ce que ça coûte : une catégorie de résultats à part, qu’il faut expliquer dans la description de l’outil pour que le modèle ne la classe pas avec les autres.
Ce qui doit durer sort de la conversation
Pourquoi : les places à 0 € apparaissent et disparaissent, une conversation ne dure pas trois semaines. Les surveillances, les alertes et le profil voyageur vivent donc côté serveur, sur un compte, avec un tableau de bord et un email plafonné à un toutes les six heures.
Ce que ça coûte : un compte à créer et une adresse personnelle à installer avant le premier usage, là où le reste marche sans rien. C’est la friction qu’on paie pour que les fonctions coûteuses restent bornées par utilisateur.
Section 04
Ce qui tourne en production
- Un serveur branché dans ChatGPT et dans Claude, sans application à installer
- Trains, bus longue distance, vols et transport urbain interrogés en parallèle
- Stratégies porte-à-porte classées, avec le lien de réservation et le repère voiture à côté
- Surveillance de places, alertes sur tableau de bord et par email
- Profil voyageur qui fixe les défauts : abonnement, arbitrage entre prix et temps
Andiamo a son propre site : getandiamo.app ↗. Ici, on explique comment il est construit.
Section 05
Ce que ça prouve
On sait livrer un produit dont l’interface est un modèle de langage : agréger des sources qui s’ignorent, borner ce qui coûte, et faire en sorte qu’une donnée incertaine se signale elle-même plutôt que d’être présentée comme une certitude.