Un beau billet une fois ne suffit pas : retour d’expérience chez Tee Off Travel

Un client prépare son départ. Il veut retrouver l’heure du premier vol, comprendre où il change d’avion et savoir quand il arrivera. Son reçu contient ces informations, mais elles voisinent avec des codes, des références et des mentions professionnelles. L’effort de lecture reste à sa charge, alors même qu’il a choisi un voyage sur mesure.

C’est ce décalage que Tee Off Travel a voulu traiter avec iSDO, le laboratoire numérique à l’origine de l’expérimentation. Le cheminement raconté ici repose sur le témoignage de Philippe Contal. Les fonctionnalités décrites ont été confrontées au code et à la documentation accessibles ; le PDF fictif permet d’observer le résultat, sans exposer un dossier client.

Charger le lecteur Spotify

Ouvrir ce lecteur autorise une connexion à Spotify, qui peut recevoir des informations de navigation.

Un voyage sur mesure, un document difficile à lire

Le reçu Amadeus remplit une fonction professionnelle. Sa densité n’est pas un défaut à tourner en dérision : il rassemble des éléments de réservation et de transport dans un format codifié. Mais un conseiller et un voyageur ne le lisent pas avec les mêmes repères. Ce qui paraît évident au premier peut demander un déchiffrage au second.

Pour Tee Off Travel, l’enjeu était donc de prolonger l’accompagnement jusque dans le document remis au client. Une présentation commune pouvait faire ressortir les étapes, distinguer l’aller du retour et rendre les correspondances plus faciles à repérer. Embellir ne suffisait pas : il fallait préserver les informations utiles et éviter qu’une mise en page rassurante donne une certitude que la source ne contient pas.

Le projet n’avait pas pour objet d’émettre un nouveau billet. Il s’agissait de reformater un reçu existant en un récapitulatif de voyage. Cette frontière détermine ce que l’outil peut expliquer et ce que le conseiller doit encore contrôler.

La promesse du tout-IA à l’épreuve des répétitions

Selon Philippe Contal, les essais entièrement fondés sur l’IA n’ont pas permis de maintenir la stabilité et la cohérence attendues dans le temps. Le témoignage ne fournit ni nombre d’essais, ni liste de modèles, ni mesure comparative. Il décrit un arbitrage de terrain : un résultat ponctuellement convaincant ne suffisait pas pour un outil destiné à l’équipe.

Une démonstration répond à la question « peut-on obtenir ce résultat ? ». Une production régulière en ajoute une autre : « peut-on compter sur une transformation suffisamment prévisible pour vérifier et remettre le document ? ». Le conseiller doit pouvoir retrouver les mêmes repères d’un dossier à l’autre, y compris lorsque certaines informations manquent.

Ce constat local ne condamne pas toutes les approches entièrement fondées sur l’IA. Il rappelle que le critère d’adoption dépend du travail à accomplir. Ici, la fidélité aux faits et la régularité de présentation pesaient davantage que la liberté de reformulation. La question rejoint celle de l’expertise qui filtre et contrôle les productions de l’IA.

Comprendre avant d’automatiser

La recherche a porté sur les bases d’aéroports et sur la documentation Amadeus, pour comprendre les conventions du reçu avant de les transformer. Le guide Amadeus précisément consulté pendant le développement n’a pas pu être identifié dans les pièces disponibles pour cet article. Il serait trompeur de lui substituer un autre document en le présentant comme une source historique du projet.

Les référentiels effectivement intégrés sont, eux, identifiables. OurAirports sert à éclairer les codes d’aéroports avec des noms et des lieux. OpenFlights fournit des références de compagnies. Leur rôle consiste à rendre des informations codées intelligibles, pas à reconstituer une réservation absente.

Cette distinction compte. Reconnaître CDG ne confirme pas l’heure du vol ; identifier un aéroport ne garantit pas qu’une correspondance soit réalisable. Les horaires viennent du document source. Les références apportent un contexte, avec leurs propres limites. Comprendre ce que chaque donnée prouve permet de mieux définir les vérifications, comme dans le passage de la veille à une capacité de construire.

Fixer les règles pour obtenir un résultat reproductible

L’arbitrage a conduit à encadrer la transformation. Le conseiller importe ou colle le document source. Les informations sont extraites selon des règles définies, puis rapprochées des références utiles. Une présentation commune organise le parcours du passager. Les informations absentes ou incertaines doivent rester visibles comme telles, au lieu d’être complétées pour donner une impression de finition.

Trois usages de l’IA doivent être distingués. Une IA peut aider à développer une application ; cela ne signifie pas qu’elle fabrique chaque document. Ici, les règles informatiques assurent la transformation et la présentation. Le code prévoit également une analyse IA complémentaire, séparée du document voyageur. Sa présence dans le code ne prouve pas son activation en production, et aucun élément vérifié pour cet article ne permet de l’affirmer.

Les contrôles du conseiller restent essentiels : concordance avec la source, dates, étapes, compagnies et informations à confirmer. Le calcul d’un intervalle entre deux vols ne constitue pas une validation de correspondance. Un document bien ordonné facilite l’examen ; il n’en transfère pas la responsabilité à la mise en page.

Ce que montre l’exemple fictif

Le reçu fictif fourni utilise Alice Martin, un numéro de billet composé de zéros et la référence DEMO01. Cet extrait conserve les libellés et les codes de la source ; les espaces ont été resserrés pour faciliter sa lecture sur mobile.

NOM: MARTIN/ALICE MRS
DATE: 08 OCT 2026
AMADEUS: DEMO01
NUMÉRO DE BILLET: ETKT 000 0000000000

BIARRITZ PAYS BASQUE
AF 7403 L 14NOV 1030
PARIS CHARLES DE GAULLE
HEURE D'ARRIVÉE: 1205
DATE D'ARRIVÉE: 14NOV
TERMINAL:2G

PARIS CHARLES DE GAULLE
AF 7952 T 14NOV 1550
TERMINAL:2F
VOL ASSURÉ PAR: AIR MAURITIUS
MAURITIUS SIR S.RAMGOOLAM INTL
HEURE D'ARRIVÉE: 0605
DATE D'ARRIVÉE: 15NOV

ATTRIBUTION DES SIÈGES
AF 7403 14NOV BIQ CDG 12A
AF 7952 14NOV CDG MRU 34A

Exemple reconstitué à partir d’un reçu Amadeus, avec des données fictives.

Le PDF présente l’aller Biarritz, Paris, Île Maurice, puis le retour, avec les dates d’arrivée et les changements de terminal. Les sièges présents dans le texte fictif ne sont pas repris dans ce PDF : ils affichent « Non renseigné ». Les cabines restent « À déterminer ». Cet écart montre précisément pourquoi le conseiller doit comparer le résultat à la source : une présentation claire ne garantit pas que toutes les informations ont été conservées.

Consulter le PDF de démonstration, non valable pour le transport.

Document produit par le générateur Tee Off Travel à partir du même exemple fictif.

La couverture est une illustration conceptuelle, pas une photographie des documents réels. Le PDF montre une sortie de démonstration ; il ne permet pas, à lui seul, de mesurer la fidélité de toutes les transformations ni leur régularité sur d’autres dossiers.

Le repère à emporter dans l’entreprise

Ce retour d’expérience ne fournit pas de gains de temps ou de réduction d’erreurs mesurés. Son apport est ailleurs : rendre explicite le travail qui sépare une belle démonstration d’un document utilisable régulièrement. La connaissance du métier, les références et les exceptions ont guidé l’arbitrage, au lieu de laisser la seule qualité visuelle décider.

Pour un dirigeant, cette grille s’applique à d’autres documents : ce qui doit rester fidèle, ce qui peut être standardisé et ce qui exige un jugement. La décision utile consiste à attribuer chaque rôle clairement. Chez Tee Off Travel, la présentation sert l’accompagnement ; elle ne remplace ni la source, ni le conseiller.