Lancer une feature IA fiable en 2 mois chez Evaneos
Faire de l'app un compagnon de voyage : le pari du Roadbook in-app
Evaneos met en relation des voyageurs avec plus de 600 agences locales dans 160 destinations. Plus de 800 000 voyages organisés depuis 2009. Une relation de confiance construite tout au long du parcours d'achat et qui disparaît presque dès que le voyageur embarque.
Le problème n'est pas l'app. C'est qu'elle n'a plus de valeur ajoutée pendant le voyage.
Une fois en destination, le voyageur se tourne vers le PDF remis par son agence : retrouver l'adresse de l'hôtel du lendemain, vérifier l'heure du transfert, appeler le chauffeur local, savoir si le dîner est inclus, confirmer quelle activité a déjà été réglée. L'app Evaneos n'existe plus à ce moment-là : ni pour lui, ni pour ses co-voyageurs.
C'est l'opportunité qu'Amélie a été missionnée : rendre le Roadbook de l'agence accessible nativement dans le mobile, et créer ainsi la première vraie raison d'ouvrir l'app pendant le voyage.
L'enjeu est double :
- Augmenter l'usage de l'app pendant le voyage et renforcer l'attribution du voyage à Evaneos. En 2025, 60 % des voyageurs ont attribué la réussite de leur voyage à la plateforme.
- Le Roadbook in-app est le levier le plus concret pour recréer de la valeur dans l'app pendant le séjour et faire progresser cet indicateur.
Objectif de la mission : créer une Beta opérationnelle pour les départs d'avril, sur un volume suffisant de voyageurs pour mesurer l’attractivité et l’adoption de cette fonctionnalité avant une généralisation.
Comprendre avant de livrer
Amélie a intégré l’équipe inTrip, une équipe autonome réunissant Product, Design, Tech et Data, organisée en cycles courts. Autour d’elle, plusieurs parties prenantes clés sur les sujets transverses : la Head of Satisfaction pour les indicateurs de réussite du voyage, l’équipe CRM & Activation pour la communication, les interlocuteurs en lien avec les agences pour sécuriser leur adhésion au projet, et l’équipe légale pour cadrer les risques liés à l’IA.
Avant d’ouvrir le backlog, elle a pris le temps de rencontrer ces interlocuteurs.
Objectif : comprendre les enjeux de chacun, identifier les zones d’incertitude et calibrer ce qu’il était réellement possible de livrer en un cycle. Ce travail de cadrage a permis de démarrer vite, sans partir sur de mauvaises hypothèses.
Premier moment de bascule : identifier le bon document source
La première décision structurante n'était pas technique. C'était une question de périmètre : parmi tous les documents qu'une agence envoie à ses voyageurs, lequel contient le Roadbook ?
Ensemble, l'équipe a rapidement identifié que le PDF était le format le plus répandu parmi les agences avec des contraintes à prendre en compte. Retenir le PDF comme source unique limitait mécaniquement le nombre d'agences éligibles à la Beta, et donc le volume de voyageurs couverts.
Un trade-off assumé collectivement : dans le cadre d'un POC, mieux vaut un périmètre restreint mais maîtrisé qu'un panel large sur des bases fragiles. Les autres formats pourraient être adressés dans les cycles suivants, une fois la valeur validée sur le terrain.
Deuxième moment de bascule : l'hétérogénéité comme contrainte centrale
L'équipe pressentait que les roadbooks d'agences seraient hétérogènes : des pratiques différentes d'une agence à l'autre, avec des formats variés, et des structures parfois très libres. De plus, une vraie zone d'ombre persistait : personne ne savait précisément à quoi ressemblaient ces documents à l'échelle du réseau d’agences, quelle part ils représentaient réellement, ni dans quelle mesure ils seraient exploitables par une extraction IA.
L'audit des documents a levé cette ambiguïté. PDFs narratifs, texte intégré dans des images, vouchers, devis transformés en roadbooks, traces GPX : il n'existait pas de format standard sur lequel bâtir une extraction fiable sans cadrage préalable. Cette découverte a changé la nature du sujet. Le vrai défi n'était plus seulement de construire un pipeline, mais de garantir que les informations extraites par l'IA resteraient fiables une fois affichées dans le mobile, malgré l'hétérogénéité des documents source.
Troisième moment de bascule : le risque légal comme contrainte d'architecture
C'est lors des échanges avec la responsable légale d'Evaneos qu'un autre enjeu est apparu. Une adresse incorrecte, une activité manquante ou un horaire erroné pouvaient exposer Evaneos à des litiges voyageurs. L'inexactitude de l'extraction devenait donc un risque business direct.
Côté agences, l'enjeu était tout aussi sensible : leur roadbook matérialise une partie de leur valeur ajoutée. Les adresses de restaurants soigneusement sélectionnées, les contacts locaux cultivés après des années de terrain, les hébergements de charme introuvables en ligne. Tout cela fait partie de leur savoir-faire. Les embarquer supposait donc de garantir une restitution fidèle, sans interprétation ni ajout non demandé du modèle.
Ces deux contraintes ont conduit à une même décision : ne pas laisser le modèle inférer ce qu'il ne trouve pas dans le document source. Sur ce sujet, la fidélité primait sur la richesse des informations.
Construire le pipeline : itérer sous contrainte
Le pipeline d’extraction, transformer un PDF en données structurées lisibles par l’app, a été le chantier le plus itératif de la mission.
La première approche reposait sur un prompt unique. Elle n’a pas tenu : trop de règles en même temps, des sorties variables selon les documents, et des informations parfois absentes ou reformulées.
L’équipe a alors découpé le pipeline en prompts spécialisés, chacun dédié à une logique précise (par exemple l'hébergement, les repas inclus ou les contacts utiles). Ce changement a rendu chaque étape testable séparément, les erreurs plus faciles à isoler, et les itérations plus rapides.
Un autre apprentissage est apparu en parallèle : la validation manuelle, utile au départ, ne pouvait pas suffire durablement. Le volume des PDFs, le temps passé par l’équipe à traiter et l’exigence de fiabilité rendaient ce fonctionnement trop fragile.
En fin de cycle, l’équipe a donc posé une base de travail plus robuste : une task force dédiée et un golden dataset, c’est-à-dire un référentiel de roadbooks associés à leur extraction idéale. Ce cadre permettait de sortir d’une vérification au cas par cas et de mesurer plus proprement la qualité du pipeline.
Le pivot est arrivé tard dans le cycle, trop tard pour en tirer tous les bénéfices immédiatement. Mais il a constitué un apprentissage structurant pour la suite.
De la donnée au mobile : construire l’expérience voyageur
Le design du Roadbook in-app n'a pas commencé avec l'arrivée d'Amélie. Alice, Product Designer de l'équipe, avait déjà lancé les premières maquettes et posé les fondations de l'expérience en parallèle du chantier technique.
Amélie est venue renforcer ce travail à un autre niveau. Ensemble, elles ont affiné le parcours autour d'un principe simple : donner accès, sans friction, aux informations les plus actionnables du séjour : étapes du voyage, hébergements, contacts utiles et document original en secours.
L'objectif : répondre aux besoins d'un voyageur qui doit trouver rapidement une information sans friction, pas apprivoiser une nouvelle interface. Les revues design, organisées toutes les deux semaines, ont permis de faire avancer les maquettes sans attendre la fin du cycle pour trancher.
Mais concevoir l'interface ne suffisait pas : encore fallait-il savoir, une fois la feature lancée, si elle créait vraiment de la valeur. Ensemble, elles ont structuré la stratégie de mesure en ce sens : NPS in-app, verbatims ouverts, taux de consultation du Roadbook, fréquence d'ouverture pendant le séjour, sections les plus consultées. Un dispositif pensé pour transformer les retours terrain en décisions produit dès le cycle suivant.
Sur ce cycle, la complémentarité entre Amélie, Product Manager, et Alice, Product Designer, a clairement accéléré le projet : Alice portait la continuité de l’expérience, Amélie le cadrage et la stratégie de mesure, avec une même direction produit et des rôles bien articulés.
Ce qu’Amélie a rendu possible en 3 mois
En trois mois, Amélie a transformé un sujet encore flou en trajectoire produit crédible : un périmètre Beta faisable, un cadre de fiabilité clair, un pipeline d’extraction structuré, 20 agences engagées, et un dispositif de mesure prêt à orienter les cycles suivants.
Surtout, cette mission a mis en lumière un apprentissage que beaucoup d’équipes font trop tard : sur un sujet IA, la qualité de la donnée source n’est pas un détail d’implémentation, c’est le premier sujet à cadrer. Amélie l’a reconnu en cours de cycle, a fait évoluer la méthode au bon moment, et a embarqué l’équipe dans ce changement sans perdre le cap.
Vous construisez une feature IA ?
Extraction de données, personnalisation, génération de contenu à partir de sources hétérogènes : ces sujets demandent un PM capable de cadrer vite, réduire le risque et aligner les équipes jusqu’au premier déploiement.
Yeita place des Senior PMs qui ont déjà opéré ce type d’arbitrages en conditions réelles. Si ce chantier ressemble à un sujet que vous avez sur votre roadmap, parlons-en.
