Tabigil : une application de voyage collaborative construite en interne

Tabigil est une application web de voyage collaborative : la carte, l'itinéraire jour par jour, le budget partagé et le guide d'un voyage de groupe, réunis au même endroit et synchronisés entre les appareils de tous les participants. C'est un produit que nous avons conçu, développé et mis en ligne en interne, pour notre propre usage : pas un projet client. Nous le documentons ici parce que c'est la preuve la plus honnête de ce que nous savons construire, avec plusieurs briques typiques d'une application métier sur mesure : comptes, données partagées, droits, temps réel.

Le contexte de départ

Le projet est né d'un besoin réel : préparer un vrai voyage de groupe. Plusieurs personnes, plusieurs mois de préparation, des dizaines de lieux à repérer, un budget commun à suivre, des étapes de randonnée à planifier. Autrement dit, le problème classique de toute organisation à plusieurs : de l'information vivante, partagée, qui doit rester fiable.

Le problème concret, et les limites des outils précédents

Avant Tabigil, la préparation vivait là où elle naît toujours : une conversation de groupe pour décider, un tableur pour le budget, une carte en ligne pour les repérages, des notes éparses pour le reste. Quatre outils, aucun lien entre eux, et les défauts habituels : personne ne sait quelle version fait foi, le budget se désynchronise dès que deux personnes le touchent, les adresses repérées se perdent dans le fil de la conversation. Ce sont exactement les symptômes que nous décrivons aux entreprises qui pilotent leur activité sur des tableurs : le problème est identique, seul le sujet change.

Ce qui a été conçu

Une application unique, accessible sur invitation, où chaque participant retrouve la même information à jour : ce que l'on décide se voit immédiatement chez les autres. L'entrée se fait par un compte personnel (invitation, embarquement guidé, réinitialisation de mot de passe), et l'application s'organise autour des moments du voyage : préparer, se déplacer, dépenser, marcher.

Les fonctionnalités principales

• Une carte collaborative : les lieux repérés par le groupe, au même endroit.
• Un itinéraire jour par jour, consultable et modifiable par tous.
• Un budget partagé, synchronisé entre les appareils.
• Un guide par destination : les informations pratiques du voyage.
• Une section transports pour les trajets du séjour.
• Un mode randonnée dédié : les étapes du jour, la progression, le plan de marche.
• Des espaces authentifiés : invitation des participants, embarquement guidé, gestion du compte.
• Un thème visuel par mode : l'interface change d'ambiance entre le voyage et la randonnée.

Les choix techniques, et pourquoi

Les choix sont ceux que nous ferions pour une application métier cliente, car le problème est le même : Next.js et React pour une interface riche qui reste rapide ; Supabase pour la base de données, l'authentification et la synchronisation temps réel sans serveur à maintenir ; Vercel pour un déploiement continu ; Vitest pour le filet de tests automatisés. Une pile volontairement sobre : chaque brique a un rôle, aucune n'est là par mode.

Le processus de conception et de développement

Le déroulé a suivi notre méthode : partir de l'usage réel (qui fait quoi pendant la préparation, puis pendant le voyage), dessiner les écrans clés autour de ces moments, produire par itérations courtes, et verrouiller chaque comportement critique par des tests automatisés au fil de l'eau. Le budget qui se recalcule, les droits d'accès, la progression d'une randonnée : tout ce qui coûterait cher à casser est testé.

Les résultats observables

Cette section ne contient que des faits vérifiables, avec leur date de contrôle :

• L'application est en ligne et fonctionnelle (tabigil.vercel.app, vérifié le 22 août 2026).
• Au contrôle du 22 août 2026, la suite comptait 433 tests automatisés, tous passants. C'est un indicateur de rigueur, pas une preuve absolue de qualité : un test vérifie ce qu'on lui demande de vérifier.
• Les parcours d'accès fonctionnent de bout en bout : invitation, création de compte, embarquement, réinitialisation de mot de passe.
• La synchronisation entre appareils est effective : une modification faite sur un téléphone apparaît sur les autres écrans du groupe.

Nous ne publions aucune métrique d'usage ni de durée de développement : nous ne communiquons que ce que nous pouvons démontrer.

Ce que nous referions différemment

• Tenir l'historique du dépôt comme une pièce du projet : l'historique antérieur du nôtre n'a pas été conservé lors d'une migration d'espace de travail, ce qui nous empêche aujourd'hui de documenter précisément la chronologie du développement. C'est précisément pour cela que cette étude n'affiche aucune durée. Depuis, la discipline est simple : un dépôt propre du premier jour, car c'est lui qui raconte honnêtement un projet.
• Documenter au fil de l'eau : captures, décisions, essais abandonnés. Cette étude de cas, écrite après coup, serait plus riche si nous avions archivé le projet en le faisant.

Ce que ce projet démontre

Interprétation assumée : Tabigil coche les mêmes cases qu'une application métier pour une entreprise : des comptes et des invitations comme dans un espace client, des données partagées qui restent cohérentes comme dans un outil interne d'équipe, et une interface qui s'organise autour des moments d'usage plutôt qu'autour de la technique. Si votre activité repose encore sur des tableurs et des conversations de groupe, c'est ce type d'outil, adapté à votre métier, que nous construisons : voyez notre offre d'applications métier sur mesure ou parlons de votre besoin.