Jauntlore est un carnet de voyage familial qui accompagne un séjour depuis sa préparation jusqu’à son souvenir. On y construit un programme, on le transforme en carnet utilisable sur téléphone, y compris sans réseau, on le partage avec les autres voyageurs et on peut ensuite l’enrichir pendant les vacances avec des photos et des commentaires. À la fin du séjour, le contenu accumulé peut également être restitué sous la forme d’un PDF que la famille conserve.
Le projet est né d’un usage strictement personnel et évolue aujourd’hui vers une version Friends & Family destinée à être testée par d’autres organisateurs. Derrière cette première ouverture se trouve une question que je n’avais pas au départ : est-ce qu’un outil fabriqué pour mes propres vacances peut devenir un véritable produit SaaS, utilisé par des personnes que je ne connais pas et pour des voyages que je n’aurai pas moi-même préparés ?
Jauntlore est aussi devenu, presque progressivement, mon terrain d’expérimentation le plus complet autour de l’IA. Je ne l’ai pas uniquement utilisée pour développer l’application : elle a participé à l’étude du marché, au cadrage du produit, à l’UX, à l’architecture, à la spécification, au développement, aux revues et aux tests. L’histoire de Jauntlore est donc autant celle d’un produit qui se construit que celle du système de travail que j’ai dû mettre en place pour continuer à le construire avec des agents.
Deux ans de préparation assistée
01 — La préparation était déjà riche
Je prépare mes voyages avec ChatGPT puis Claude depuis environ deux ans. Je décris le séjour, les personnes qui viennent, nos envies, les contraintes à prendre en compte et les lieux que nous envisageons ; la conversation se précise progressivement jusqu’à produire un programme assez détaillé, que je complète et réorganise au fil des échanges.
Pour le Tyrol à l’été 2025, ce travail avait fini dans un support de dix-huit pages. Chaque journée comportait son programme, ses trajets, ses cartes et différentes informations pratiques. À Sölden, j’avais par exemple intégré les remontées mécaniques, les randonnées, l’Aquadome et les contraintes liées au chien ; Innsbruck était organisé entre matinée, déjeuner et après-midi, là encore en tenant compte très concrètement des conditions d’accès avec Réglisse. La préparation était donc déjà beaucoup plus riche que ce que j’aurais produit seul quelques années auparavant.
Une fois le document terminé, en revanche, je l’exportais en PDF, je le partageais dans notre conversation familiale WhatsApp et il restait ensuite pratiquement figé. Il fallait le parcourir pour retrouver l’information utile, il ne savait évidemment pas où nous en étions dans le séjour et il ne conservait rien de ce que nous allions finalement découvrir ou modifier sur place. L’IA avait considérablement enrichi ma manière de préparer les vacances, mais le support utilisé pendant le voyage avait, lui, très peu évolué.
Du document au carnet vivant
02 — Le document part en voyage
Quelques mois plus tard, pour un séjour à Bordeaux, j’ai essayé de changer cette dernière partie. À partir du même type de préparation, j’ai demandé à Claude de produire une petite application Web plutôt qu’un nouveau document. Le contenu n’était pas fondamentalement différent, mais son usage l’était : je pouvais naviguer dans les journées, retrouver beaucoup plus naturellement ce qui concernait le moment présent et donner une forme plus agréable au programme préparé avant le départ.
Pour nos vacances à Salò, en Italie, j’ai décidé de pousser cette idée beaucoup plus loin. L’application devait fonctionner correctement sur téléphone et rester utile lorsque le réseau devenait mauvais ou inexistant. Elle regroupait le programme quotidien, les lieux et les informations pratiques, mais aussi des quiz, une chasse au trésor et plusieurs mécanismes destinés aux enfants. Le carnet a finalement accompagné 24 journées et trois semaines de vacances ; les membres de ma famille l’ouvraient eux-mêmes pour regarder ce qui était prévu ou retrouver une information, tandis que les plus jeunes y revenaient aussi pour les jeux.
L’usage ne s’arrêtait plus à la consultation du programme préparé à l’avance. Pendant le séjour, nous pouvions ajouter des photos et des commentaires sur ce que nous avions réellement vécu, puis retrouver ces éléments dans le carnet. À la fin, l’application pouvait à son tour produire un PDF enrichi de ces souvenirs. Le PDF n’avait donc pas disparu : dans le Tyrol, il constituait le résultat final de la préparation ; avec Jauntlore, il peut devenir le résultat final du voyage, après qu’un même carnet a accompagné les différentes étapes entre les deux.
Séparer le produit du voyage
03 — Ce qui fonctionne pour un voyage ne fait pas encore un produit
Le carnet de Salò avait naturellement été conçu autour de notre propre voyage. Le lac de Garde était présent dans son identité graphique, certaines informations correspondaient précisément à nos dates et à nos observations sur place, et plusieurs textes, easter eggs ou comportements n’avaient de sens que dans ce contexte. Tant que l’application restait destinée à ma famille, cette proximité entre le produit et le voyage ne posait pas vraiment de problème.
Elle en a posé un dès que j’ai commencé à envisager que d’autres personnes puissent préparer leur propre carnet. Une part importante de la V2 consiste depuis à séparer ce qui appartient à Jauntlore, ce qui doit appartenir à chaque voyage et ce qui doit rester propre à Salò. Ce travail de généralisation a d’ailleurs révélé plusieurs dépendances que je n’avais pas forcément anticipées : certaines règles ou certaines données héritées du premier carnet pouvaient encore influencer un autre voyage alors qu’elles auraient dû rester strictement isolées.
C’est en travaillant sur ces frontières que le positionnement du produit s’est lui-même précisé. Jauntlore n’est pas un assistant IA chargé de générer un itinéraire ; c’est un espace permettant de préparer, enrichir, partager et vivre un voyage à plusieurs. L’IA y conserve une place importante, mais elle n’en constitue pas la finalité. C’est aussi pour cette raison que l’import est devenu un parcours de premier rang : quelqu’un peut très bien préparer son voyage avec Claude, ChatGPT, Gemini ou un autre outil, puis apporter ce travail dans Jauntlore sans avoir besoin de recommencer la préparation avec l’assistant intégré.
Ne pas confondre les registres
04 — Passer de mon usage à une hypothèse SaaS
À ce stade, mes meilleures preuves venaient encore de mon propre usage et de celui de ma famille. Elles suffisaient pour savoir que le carnet avait un intérêt pour nous, mais certainement pas pour conclure qu’il existait un marché autour de cette idée. Avant d’investir davantage dans une version générique, j’ai donc voulu confronter l’intuition à ce qui existait déjà et à ce que l’on pouvait réellement observer du marché.
J’ai utilisé l’IA pour mener une recherche structurée sur les concurrents, les substituts, l’usage des assistants génératifs pour préparer les voyages, les frustrations exprimées par les utilisateurs, les questions de confiance dans les recommandations, la gamification familiale ou encore une éventuelle disposition à payer. Wanderlog, TripIt, Roadtrippers, Mindtrip, Polarsteps et d’autres produits occupent déjà une partie de cet espace ; dans le même temps, ChatGPT, Claude, les documents, les tableurs ou WhatsApp constituent eux aussi des alternatives très réelles à un produit dédié.
La recherche a confirmé que l’IA prenait une place croissante dans la préparation des voyages, mais elle n’a fourni aucune preuve suffisamment solide pour affirmer que le segment précis visé par Jauntlore était assez large ou que les familles seraient prêtes à payer pour ce type de service. Ce résultat m’a surtout permis de constater que la recherche documentaire avait atteint sa limite : continuer à accumuler des chiffres sur le Web n’allait pas répondre aux questions principales. J’ai donc transformé les inconnues restantes en hypothèses à tester dans un pilote Friends & Family, en distinguant explicitement les faits, les éléments issus de sources extérieures, les hypothèses et les décisions déjà prises.
Fait
- ce que j’ai réellement observé
Preuve extérieure
- ce que montre la recherche
Hypothèse
- ce que je pense possible mais ne sais pas encore
Décision
- ce que j’ai choisi de faire
À tester
- ce que le pilote doit confronter à l’usage
Presque toute la chaîne
05 — L’IA participe presque partout
Claude a progressivement participé à beaucoup plus que l’implémentation de Jauntlore. Je l’ai utilisé pour explorer le marché, structurer des hypothèses produit, travailler le PRD, challenger l’UX et l’architecture, préparer les Stories et les spécifications, produire du code, analyser les erreurs et conduire des revues. Cette continuité entre les différentes étapes permet d’avancer rapidement et de conserver beaucoup de contexte, mais elle crée aussi un risque de confusion entre des éléments qui n’ont pas la même valeur.
Une information trouvée lors d’une recherche n’est pas une décision produit, pas plus qu’une proposition d’architecture ne devient une règle simplement parce qu’elle paraît convaincante. De la même manière, le fait qu’un agent annonce avoir terminé une implémentation ne signifie pas encore que cette implémentation a réellement été vérifiée. J’ai donc cherché à rendre ces passages de plus en plus explicites, avec des artefacts différents selon la nature du travail et des points de décision où l’automatisation doit s’arrêter.
BMAD m’a fourni une grande partie de cette structure avec les Briefs, PRD, architectures, Epics, Stories, spécifications et revues. Je ne m’en sers pas avec l’objectif d’accumuler de la documentation, mais parce que ces artefacts permettent de retrouver ce qui a été observé, ce qui a été proposé, ce qui a réellement été décidé et ce qui a finalement été vérifié. À mesure que le projet a grandi, le volume de ces passages entre agents, artefacts, décisions et contrôles a cependant commencé à rendre leur coordination manuelle de plus en plus coûteuse.
Orchestrer le travail des agents
06 — J’ai fini par orchestrer le delivery lui-même
Au début du projet, une Story suffisamment précise, un bon contexte et une revue attentive suffisaient généralement pour enchaîner les étapes. Avec l’augmentation du nombre de Stories et du nombre de rôles impliqués, la situation s’est compliquée : après une correction, il faut savoir quelles preuves restent encore valables ; lorsqu’une décision humaine interrompt le travail, il faut pouvoir reprendre exactement au bon endroit ; un changement de code peut rendre une revue précédente obsolète, tandis qu’une correction produite par un agent doit parfois être relue par un autre avant que le cycle puisse continuer.
Une part croissante de mon temps servait donc à coordonner cette mécanique plutôt qu’à travailler directement sur le produit. J’ai d’abord formalisé ces règles dans un Delivery Orchestrator maison, puis j’ai fait évoluer son runtime vers LangGraph afin notamment de conserver l’état d’un run, de reprendre après une interruption et de gérer plus proprement les passages nécessitant une décision humaine.
BMAD et LangGraph jouent ici deux rôles complémentaires. BMAD structure une grande partie du travail produit et des artefacts qui l’accompagnent ; LangGraph m’aide à orchestrer l’exécution de ce travail dans la durée. En développant Jauntlore avec des agents, j’ai donc progressivement commencé à développer aussi le système chargé d’organiser leur travail, jusqu’à ce que ce système devienne lui-même un nouvel objet d’expérimentation.
Quand le contrôle se trompe
07 — Quand les garde-fous donnent eux-mêmes de faux signaux
En structurant davantage mon SDLC avec BMAD, puis en automatisant une partie de son exécution avec LangGraph, j’ai commencé à rencontrer un autre type de problème : les contrôles destinés à sécuriser le travail pouvaient eux-mêmes donner une image incorrecte de la situation. Un premier cas est apparu avec l’assistant conversationnel, lorsque plus d’une centaine de tests et plusieurs revues ont laissé passer deux défauts qui ne se manifestaient qu’avec de vrais échanges avec le modèle. J’ai donc ajouté une autre forme de vérification, en rejouant régulièrement de véritables conversations avec l’IA en dehors des tests automatisés classiques.
Un second incident concernait la CI. GitHub affichait un contrôle au vert alors que, pour la modification concernée, les tests n’avaient en réalité pas été exécutés. Le workflow avait bien terminé son propre travail sans erreur, mais j’interprétais ce résultat comme une preuve que je ne possédais pas. J’ai corrigé à la fois le défaut découvert et le mécanisme qui devait garantir que les tests concernés se déclenchent lorsqu’un fichier dont ils dépendent est modifié.
Le cas le plus instructif est ensuite venu d’un run orchestré avec LangGraph qui a cumulé 9 cycles de correction, 12 revues, 50 problèmes détectés et 10 problèmes bloquants. Chaque passage corrigeait effectivement quelque chose, mais de nouvelles incohérences continuaient à apparaître ailleurs. L’analyse a montré que certaines règles importantes avaient été recopiées dans de nombreux endroits du produit ; dans un cas, une règle que je pensais présente quatre fois existait en réalité vingt fois, et certains tests protégeaient même une ancienne valeur devenue incorrecte.
Cet épisode m’a conduit à revoir plusieurs choix d’architecture. Lorsqu’une règle est suffisamment importante pour être contrôlée à de nombreux endroits, je cherche désormais d’abord à réduire le nombre d’endroits où elle peut être définie plutôt qu’à multiplier les vérifications autour de copies supposées identiques. BMAD et LangGraph n’ont donc pas rendu le delivery infaillible ; ils ont surtout rendu son fonctionnement suffisamment explicite pour que les défauts du système de contrôle deviennent eux aussi visibles et puissent être traités.
- cycles de correction
- 9
- revues
- 12
- problèmes détectés
- 50
- bloquants
- 10
Un seul run orchestré, et chaque passage corrigeait pourtant bien quelque chose.
Le pilote Friends & Family
08 — Le prochain test ne sera plus le mien
Jauntlore arrive maintenant à une étape différente de celles que j’ai traversées jusqu’ici. Le carnet terrain a accompagné un vrai voyage, une grande partie des particularités de Salò est progressivement séparée du produit générique et l’expérience de préparation évolue afin que d’autres organisateurs puissent l’utiliser sans intervention technique de ma part. Le pilote Friends & Family doit réunir une dizaine à une vingtaine de personnes et constituer la première confrontation réellement structurée avec des utilisateurs extérieurs à ma famille.
Je veux notamment observer la manière dont ils commencent un voyage, s’ils préfèrent préparer directement dans Jauntlore ou importer ce qu’ils ont déjà construit avec leur assistant habituel, si la distinction entre les informations vérifiées et celles qui restent incertaines leur apporte réellement quelque chose, et ce qu’ils utilisent une fois sur le terrain. L’objectif du pilote n’est pas de confirmer coûte que coûte le produit que j’ai déjà en tête, mais également de faire disparaître les idées qui ne résistent pas à l’usage.
Jusqu’ici, je pouvais décider de construire une fonctionnalité parce qu’elle répondait bien aux besoins de ma famille, puis mesurer ensuite sa qualité technique. Si Jauntlore doit devenir autre chose qu’un logiciel personnel particulièrement abouti, ce niveau de preuve ne suffit plus. La prochaine étape dépendra donc moins d’une nouvelle Story ou d’un nouveau développement que de ce que feront des personnes pour lesquelles je n’aurai pas préparé le voyage moi-même.